perm filename CLCLEA.MSG[COM,LSP]11 blob
sn#873054 filedate 1989-05-04 generic text, type C, neo UTF8
COMMENT ⊗ VALID 00307 PAGES
C REC PAGE DESCRIPTION
C00001 00001
C00043 00002
C00044 00003 ∂13-Mar-89 1254 CL-Cleanup-mailer amendments to already passed issues
C00046 00004 ∂13-Mar-89 1352 CL-Cleanup-mailer Issue: LOAD-OBJECTS (Version 3)
C00053 00005 ∂13-Mar-89 1448 CL-Cleanup-mailer Issue: LOAD-TRUENAME (Version 1)
C00061 00006 ∂13-Mar-89 1457 CL-Cleanup-mailer Issue CLOS-CONDITIONS, v4
C00063 00007 ∂13-Mar-89 1457 CL-Cleanup-mailer gls cleanups
C00065 00008 ∂13-Mar-89 1500 CL-Cleanup-mailer Issue ERROR-CHECKING-IN-NUMBERS-CHAPTER
C00067 00009 ∂13-Mar-89 1501 CL-Cleanup-mailer Issue SUBTYPEP-TOO-VAGUE
C00070 00010 ∂13-Mar-89 1502 CL-Cleanup-mailer Issue PEEK-CHAR-READ-CHAR-ECHO
C00076 00011 ∂13-Mar-89 1457 CL-Compiler-mailer Issue LOCALLY-TOP-LEVEL, v1
C00078 00012 ∂13-Mar-89 1557 CL-Cleanup-mailer Issue LOCALLY-TOP-LEVEL, v1
C00081 00013 ∂13-Mar-89 1726 CL-Cleanup-mailer Re: issue PROCLAIM-LEXICAL (Version 9)
C00083 00014 ∂13-Mar-89 1737 CL-Compiler-mailer Re: Issue: LOAD-OBJECTS (Version 3)
C00088 00015 ∂13-Mar-89 1754 CL-Compiler-mailer Re: Issue: LOAD-OBJECTS (Version 3)
C00092 00016 ∂14-Mar-89 0738 CL-Cleanup-mailer Re: Issue PEEK-CHAR-READ-CHAR-ECHO
C00096 00017 ∂14-Mar-89 0738 CL-Cleanup-mailer More re: PEEK-CHAR-READ-CHAR-ECHO
C00098 00018 ∂14-Mar-89 0756 CL-Cleanup-mailer Re: Issue: DESTRUCTURING-BIND (Version 2)
C00100 00019 ∂14-Mar-89 0835 CL-Cleanup-mailer Re: Issue: CONDITION-RESTARTS (Version 1)
C00102 00020 ∂14-Mar-89 0923 CL-Cleanup-mailer More re: PEEK-CHAR-READ-CHAR-ECHO
C00105 00021 ∂14-Mar-89 1104 CL-Cleanup-mailer Re: Issue IGNORE-VARIABLE, v1
C00114 00022 ∂14-Mar-89 1253 CL-Cleanup-mailer re: PATHNAME-PRINT-READ, v1
C00117 00023 ∂14-Mar-89 1317 CL-Cleanup-mailer Re: PATHNAME-PRINT-READ, v1
C00120 00024 ∂14-Mar-89 1344 CL-Cleanup-mailer Re: Issue: LOAD-TRUENAME (Version 1)
C00122 00025 ∂14-Mar-89 1344 CL-Cleanup-mailer Re: Issue: CLOS-CONDITIONS (Version 4)
C00125 00026 ∂14-Mar-89 1344 CL-Cleanup-mailer Issue: LOAD-TRUENAME (Version 1)
C00127 00027 ∂14-Mar-89 1358 CL-Cleanup-mailer Issue: TIME-ZONE-NON-INTEGER
C00129 00028 ∂14-Mar-89 1505 CL-Cleanup-mailer Issue: ERROR-NOT-HANDLED (Version 1)
C00131 00029 ∂14-Mar-89 1612 CL-Cleanup-mailer TYPE-OF-UNDERCONSTRAINED, version 4
C00141 00030 ∂14-Mar-89 1613 CL-Cleanup-mailer SYMBOL-MACROLET-SEMANTICS, version 6
C00153 00031 ∂14-Mar-89 1731 CL-Cleanup-mailer Re: Issue: READ-CASE-SENSITIVITY (Version 1)
C00156 00032 ∂14-Mar-89 1731 CL-Cleanup-mailer RE: Cleanup Issue Status
C00161 00033 ∂14-Mar-89 1732 CL-Cleanup-mailer revised: Cleanup Issue Status
C00165 00034 ∂14-Mar-89 1732 CL-Cleanup-mailer Issue: PRETTY-PRINT-INTERFACE (Version 1)
C00167 00035 ∂14-Mar-89 1732 CL-Compiler-mailer Re: Potential issue: MACRO-SPECIAL-FORMS
C00169 00036 ∂14-Mar-89 1743 CL-Cleanup-mailer Issue: FORMAT-PLURALS (not yet submitted)
C00178 00037 ∂14-Mar-89 1756 CL-Cleanup-mailer Re: Issue: COPY-SYMBOL-PRINT-NAME (Version 1)
C00180 00038 ∂14-Mar-89 1812 CL-Cleanup-mailer Re: Issue: READ-CASE-SENSITIVITY (Version 1)
C00183 00039 ∂15-Mar-89 0542 CL-Cleanup-mailer Issue: COPY-SYMBOL-PRINT-NAME
C00188 00040 ∂15-Mar-89 0549 CL-Cleanup-mailer Issue: EQUAL-STRUCTURE (Version 7)
C00200 00041 ∂15-Mar-89 0641 CL-Cleanup-mailer Re: Issue: OPTIMIZE-SAFETY (Version 1)
C00202 00042 ∂15-Mar-89 0720 CL-Cleanup-mailer Re: Issue ERROR-CHECKING-IN-NUMBERS-CHAPTER
C00205 00043 ∂15-Mar-89 0720 CL-Cleanup-mailer
C00246 00044 ∂15-Mar-89 0741 CL-Cleanup-mailer Re: Issue: PLUS-ABNORMAL (Version 1)
C00250 00045 ∂15-Mar-89 0817 CL-Cleanup-mailer Cleanup Issue Status
C00252 00046 ∂15-Mar-89 0845 CL-Cleanup-mailer Re: Cleanup Issue Status
C00255 00047 ∂15-Mar-89 0921 CL-Cleanup-mailer Re: Cleanup Issue Status
C00259 00048 ∂15-Mar-89 0930 CL-Cleanup-mailer Issue: PRETTY-PRINT-INTERFACE (Version 1)
C00262 00049 ∂15-Mar-89 0934 CL-Cleanup-mailer RE: Cleanup Issue Status
C00265 00050 ∂15-Mar-89 0936 CL-Cleanup-mailer Issue: ADJUST-ARRAY-NOT-ADJUSTABLE (Version 8)
C00267 00051 ∂15-Mar-89 0947 CL-Cleanup-mailer Issue: COPY-SYMBOL-PRINT-NAME
C00269 00052 ∂15-Mar-89 0959 CL-Cleanup-mailer Issue: TIME-ZONE-NON-INTEGER
C00271 00053 ∂15-Mar-89 0948 X3J13-mailer Issue: GENSYM-NAME-STICKINESS (Version 1)
C00273 00054 ∂15-Mar-89 1045 CL-Cleanup-mailer Issue: GENSYM-NAME-STICKINESS (Version 1)
C00278 00055 ∂15-Mar-89 1057 CL-Cleanup-mailer Issue LOOP-AND-DISCREPANCY, version 1
C00284 00056 ∂15-Mar-89 1111 CL-Cleanup-mailer Issue: COPY-SYMBOL-COPY-PLIST
C00286 00057 ∂15-Mar-89 1127 CL-Cleanup-mailer Issue: REAL-NUMBER-TYPE (version 3)
C00299 00058 ∂15-Mar-89 1138 CL-Cleanup-mailer Issue: REMF-DESTRUCTION-UNSPECIFIED (Version 4)
C00319 00059 ∂15-Mar-89 1145 CL-Cleanup-mailer Issue: REAL-NUMBER-TYPE (version 3)
C00323 00060 ∂15-Mar-89 1147 CL-Cleanup-mailer Issue: MAKE-STRING-FILL-POINTER (Version 1)
C00328 00061 ∂15-Mar-89 1208 CL-Cleanup-mailer Issue status
C00330 00062 ∂15-Mar-89 1227 CL-Cleanup-mailer Re: issue PROCLAIM-LEXICAL (Version 9)
C00333 00063 ∂15-Mar-89 1229 CL-Cleanup-mailer Re: Issue: READ-CASE-SENSITIVITY (Version 1)
C00336 00064 ∂15-Mar-89 1256 CL-Cleanup-mailer PRETTY-PRINT-INTERFACE, version 3 (supersedes 2 sent an hour ago!)
C00360 00065 ∂15-Mar-89 1306 CL-Cleanup-mailer Issue: GENSYM-NAME-STICKINESS, version 2
C00368 00066 ∂15-Mar-89 1449 CL-Cleanup-mailer Issue SUBTYPEP-TOO-VAGUE, version 5
C00378 00067 ∂15-Mar-89 1454 CL-Cleanup-mailer [gls: Issue SUBTYPEP-TOO-VAGUE, version 5]
C00389 00068 ∂15-Mar-89 1756 CL-Cleanup-mailer Re: Issue LOCALLY-TOP-LEVEL, v1
C00391 00069 ∂15-Mar-89 1907 CL-Cleanup-mailer Re: Issue STREAM-ACCESS
C00393 00070 ∂16-Mar-89 0523 CL-Cleanup-mailer Re: Issue: GENSYM-NAME-STICKINESS, version 2
C00395 00071 ∂16-Mar-89 0646 CL-Cleanup-mailer Issue: GENSYM-NAME-STICKINESS, version 2
C00397 00072 ∂16-Mar-89 0807 CL-Cleanup-mailer Re: Issue: BREAK-ON-WARNINGS-OBSOLETE (Version 1)
C00400 00073 ∂16-Mar-89 0827 CL-Cleanup-mailer Re: Issue: BREAK-ON-WARNINGS-OBSOLETE (Version 1)
C00403 00074 ∂16-Mar-89 0831 CL-Cleanup-mailer Re: issue PROCLAIM-LEXICAL (Version 9)
C00405 00075 ∂16-Mar-89 0917 CL-Cleanup-mailer Issue LOOP-AND-DISCREPANCY, version 1
C00407 00076 ∂16-Mar-89 0932 CL-Cleanup-mailer Re: issue PROCLAIM-LEXICAL (Version 9)
C00410 00077 ∂16-Mar-89 1044 CL-Cleanup-mailer Re: issue PROCLAIM-LEXICAL (Version 9)
C00412 00078 ∂16-Mar-89 1115 CL-Cleanup-mailer Issue: GENSYM-NAME-STICKINESS, version 2
C00415 00079 ∂16-Mar-89 1143 CL-Cleanup-mailer Re: DRAFT Issue: CONDITION-RESTARTS (Version 1)
C00417 00080 ∂16-Mar-89 1234 CL-Cleanup-mailer Re: Issue: BREAK-ON-WARNINGS-OBSOLETE (Version 1)
C00421 00081 ∂16-Mar-89 1252 CL-Cleanup-mailer DEFAULT-CASE
C00429 00082 ∂16-Mar-89 1318 CL-Cleanup-mailer Issue: REMF-DESTRUCTION-UNSPECIFIED (Version 5)
C00432 00083 ∂16-Mar-89 1338 CL-Cleanup-mailer Issue: ENVIRONMENT-ENQUIRY (not submitted)
C00434 00084 ∂16-Mar-89 1338 CL-Cleanup-mailer Re: Issue EQUALP-GENERIC
C00435 00085 ∂16-Mar-89 1440 CL-Cleanup-mailer Re: issue PROCLAIM-LEXICAL (Version 9)
C00437 00086 ∂16-Mar-89 1518 CL-Cleanup-mailer DEFAULT-CASE
C00440 00087 ∂16-Mar-89 1555 CL-Cleanup-mailer Issue: REMF-DESTRUCTION-UNSPECIFIED (Version 5)
C00444 00088 ∂16-Mar-89 1605 CL-Cleanup-mailer Issue: REMF-DESTRUCTION-UNSPECIFIED (Version 5)
C00449 00089 ∂16-Mar-89 1802 CL-Cleanup-mailer Issue: TYPE-OF-UNDERCONSTRAINED, v.5
C00460 00090 ∂16-Mar-89 2116 CL-Cleanup-mailer Re: Issue: EXPT-ZERO-ZERO (Version 1)
C00462 00091 ∂16-Mar-89 2212 CL-Cleanup-mailer Issue: FIXNUM-NON-PORTABLE, v.5
C00471 00092 ∂16-Mar-89 2253 CL-Cleanup-mailer Re: DEFAULT-CASE
C00476 00093 ∂16-Mar-89 2310 CL-Cleanup-mailer Re: Issue: IN-SYNTAX (Version 1)
C00478 00094 ∂17-Mar-89 0009 CL-Cleanup-mailer Cleanup Issue Status List
C00524 00095 ∂17-Mar-89 0823 CL-Cleanup-mailer Re: DEFAULT-CASE
C00529 00096 ∂17-Mar-89 0838 CL-Cleanup-mailer Issue: FUNCTION-COERCE-TIME (Version 2)
C00531 00097 ∂17-Mar-89 0847 CL-Cleanup-mailer Re: DEFAULT-CASE
C00536 00098 ∂17-Mar-89 0859 CL-Cleanup-mailer Re: issue HASH-TABLE-PRINTED-REPRESENTATION, v.2
C00541 00099 ∂17-Mar-89 0910 CL-Cleanup-mailer Re: Issue: COERCE-INCOMPLETE (Version 3)
C00545 00100 ∂17-Mar-89 1032 CL-Cleanup-mailer DYNAMIC-EXTENT
C00548 00101 ∂17-Mar-89 1044 CL-Cleanup-mailer Re: DEFAULT-CASE
C00553 00102 ∂17-Mar-89 1046 CL-Cleanup-mailer Re: issue PROCLAIM-LEXICAL (Version 9)
C00556 00103 ∂17-Mar-89 1100 CL-Cleanup-mailer Issue: CONDITION-RESTARTS (Version 1)
C00559 00104 ∂17-Mar-89 1101 CL-Cleanup-mailer Issue: CONDITION-RESTARTS (Version 1)
C00562 00105 ∂17-Mar-89 1205 CL-Cleanup-mailer Issue: IN-SYNTAX (Version 1)
C00564 00106 ∂17-Mar-89 1214 CL-Cleanup-mailer Issue LOOP-AND-DISCREPANCY, version 1
C00566 00107 ∂17-Mar-89 1214 CL-Cleanup-mailer Issue: ADJUST-ARRAY-NOT-ADJUSTABLE (Version 6)
C00569 00108 ∂17-Mar-89 1214 CL-Cleanup-mailer Issue: ADJUST-ARRAY-NOT-ADJUSTABLE (Version 8)
C00574 00109 ∂17-Mar-89 1229 CL-Cleanup-mailer DYNAMIC-EXTENT
C00578 00110 ∂17-Mar-89 1254 CL-Cleanup-mailer Re: DEFAULT-CASE
C00584 00111 ∂17-Mar-89 1254 CL-Cleanup-mailer Issue: ADJUST-ARRAY-NOT-ADJUSTABLE (Version 8)
C00587 00112 ∂17-Mar-89 1257 X3J13-mailer Issue: ADJUST-ARRAY-NOT-ADJUSTABLE (Version 8)
C00590 00113 ∂17-Mar-89 1327 CL-Cleanup-mailer DYNAMIC-EXTENT
C00594 00114 ∂17-Mar-89 1337 CL-Cleanup-mailer Issue: ADJUST-ARRAY-NOT-ADJUSTABLE (Version 9)
C00609 00115 ∂17-Mar-89 1346 CL-Cleanup-mailer Issue: ADJUST-ARRAY-NOT-ADJUSTABLE (Version 6)
C00614 00116 ∂17-Mar-89 1410 CL-Cleanup-mailer Re: Issue: EXPT-ZERO-ZERO (Version 1)
C00617 00117 ∂17-Mar-89 1541 CL-Cleanup-mailer Issue: ADJUST-ARRAY-NOT-ADJUSTABLE (Version 8)
C00621 00118 ∂17-Mar-89 1555 CL-Cleanup-mailer Issue: ADJUST-ARRAY-NOT-ADJUSTABLE (Version 6)
C00624 00119 ∂17-Mar-89 1618 CL-Cleanup-mailer Issue: CONDITION-RESTARTS (Version 1)
C00632 00120 ∂17-Mar-89 1627 CL-Cleanup-mailer Issue: PACKAGE-FUNCTION-CONSISTENCY (version 4)
C00639 00121 ∂17-Mar-89 1600 X3J13-mailer Issue: ADJUST-ARRAY-NOT-ADJUSTABLE (Version 8)
C00641 00122 ∂17-Mar-89 1613 X3J13-mailer Issue: ADJUST-ARRAY-NOT-ADJUSTABLE (Version 8)
C00644 00123 ∂17-Mar-89 1657 CL-Cleanup-mailer Issue: FIXNUM-NON-PORTABLE, v.5
C00647 00124 ∂17-Mar-89 1656 X3J13-mailer Issue: ADJUST-ARRAY-NOT-ADJUSTABLE (Version 8)
C00653 00125 ∂17-Mar-89 1839 CL-Cleanup-mailer Re: Issue: FIXNUM-NON-PORTABLE, v.5
C00654 00126 ∂17-Mar-89 1949 CL-Cleanup-mailer Re: Issue: CONDITION-RESTARTS (Version 1)
C00656 00127 ∂17-Mar-89 2009 CL-Cleanup-mailer Issue: DEFMACRO-LAMBDA-LIST, v.2
C00665 00128 ∂17-Mar-89 2126 CL-Cleanup-mailer New issue: WITH-OPEN-FILE-DOES-NOT-EXIST
C00671 00129 ∂17-Mar-89 2128 CL-Cleanup-mailer Re: DEFAULT-CASE
C00673 00130 ∂17-Mar-89 2140 CL-Cleanup-mailer Issue: TYPE-OF-UNDERCONSTRAINED, v.5
C00679 00131 ∂17-Mar-89 2153 CL-Cleanup-mailer Re: Issue: READ-CASE-SENSITIVITY (Version 1)
C00682 00132 ∂17-Mar-89 2223 CL-Cleanup-mailer Re: Issue: TYPE-OF-UNDERCONSTRAINED, v.5
C00685 00133 ∂17-Mar-89 2235 CL-Cleanup-mailer Issue: PRETTY-PRINT-INTERFACE (version 3)
C00692 00134 ∂17-Mar-89 2254 CL-Cleanup-mailer Re: Issue: LOAD-OBJECTS (Version 3)
C00698 00135 ∂17-Mar-89 2300 CL-Cleanup-mailer Re: Issue: TYPE-OF-UNDERCONSTRAINED, v.5
C00702 00136 ∂17-Mar-89 2320 CL-Cleanup-mailer Re: Issue: PLUS-ABNORMAL (Version 1)
C00703 00137 ∂17-Mar-89 2357 CL-Cleanup-mailer Re: environment argument for SUBTYPEP
C00705 00138 ∂18-Mar-89 0026 CL-Cleanup-mailer [cl-cleanup@sail.stanford.edu: Issue:
C00717 00139 ∂18-Mar-89 0122 CL-Cleanup-mailer Cleanup Issue Status List
C00761 00140 ∂18-Mar-89 0216 CL-Cleanup-mailer Issue: REMF-DESTRUCTION-UNSPECIFIED (Version 5)
C00782 00141 ∂18-Mar-89 1708 CL-Cleanup-mailer *DRAFT* Issue: DESTRUCTURING-BIND, v.2
C00784 00142 ∂18-Mar-89 1720 CL-Cleanup-mailer Issue DESCRIBE-UNDERSPECIFIED, v.1
C00787 00143 ∂18-Mar-89 2312 CL-Cleanup-mailer Issue: DEFMACRO-LAMBDA-LIST, v.2
C00790 00144 ∂19-Mar-89 1058 CL-Cleanup-mailer Issue: HASH-TABLE-ACCESS (version 2)
C00793 00145 ∂20-Mar-89 1229 CL-Cleanup-mailer Re: Issue: PRETTY-PRINT-INTERFACE (version 3)
C00797 00146 ∂20-Mar-89 1236 CL-Cleanup-mailer Re: Issue: PRETTY-PRINT-INTERFACE (version 3)
C00801 00147 ∂20-Mar-89 1241 CL-Cleanup-mailer Issue: COMPLEX-RATIONAL-RESULT (version 1)
C00807 00148 ∂20-Mar-89 1241 CL-Cleanup-mailer Issue: HASH-TABLE-SIZE (version 1)
C00812 00149 ∂20-Mar-89 1242 CL-Cleanup-mailer Issue: PATHNAME-COMPONENT-VALUE (version 1)
C00825 00150 ∂20-Mar-89 1241 CL-Cleanup-mailer Issue: COMMON-TYPE (version 1)
C00829 00151 ∂20-Mar-89 1325 CL-Cleanup-mailer Re: Issue: LOAD-OBJECTS (Version 3)
C00831 00152 ∂20-Mar-89 1415 CL-Cleanup-mailer Re: Issue: PRETTY-PRINT-INTERFACE (version 3)
C00836 00153 ∂20-Mar-89 1427 CL-Cleanup-mailer Re: Issue: LOAD-OBJECTS (Version 3)
C00838 00154 ∂20-Mar-89 1437 CL-Cleanup-mailer Issue: COMMON-TYPE (version 1)
C00840 00155 ∂20-Mar-89 1438 CL-Cleanup-mailer Issue: COMMON-TYPE (version 1)
C00842 00156 ∂20-Mar-89 1507 CL-Cleanup-mailer Issue: COMPLEX-RATIONAL-RESULT (version 1)
C00844 00157 ∂20-Mar-89 1512 CL-Cleanup-mailer Issue: HASH-TABLE-SIZE (version 1)
C00846 00158 ∂20-Mar-89 1556 CL-Cleanup-mailer Issue: PRETTY-PRINT-INTERFACE (version 3)
C00853 00159 ∂20-Mar-89 1605 CL-Cleanup-mailer Issue: FIXNUM-NON-PORTABLE, v.5
C00857 00160 ∂20-Mar-89 1841 CL-Cleanup-mailer Issue: PRETTY-PRINT-INTERFACE (version 3)
C00865 00161 ∂20-Mar-89 2059 CL-Cleanup-mailer Issue: PATHNAME-COMPONENT-VALUE (version 1)
C00869 00162 ∂21-Mar-89 0845 CL-Cleanup-mailer Issue: GENSYM-NAME-STICKINESS (Version 3)
C00878 00163 ∂21-Mar-89 1503 CL-Cleanup-mailer New cleanup issues
C00880 00164 ∂21-Mar-89 1601 CL-Cleanup-mailer New issue: WITH-OPEN-FILE-DOES-NOT-EXIST
C00882 00165 ∂21-Mar-89 1643 CL-Cleanup-mailer Issue: PATHNAME-COMPONENT-VALUE (version 1)
C00889 00166 ∂21-Mar-89 1752 CL-Cleanup-mailer Issue: PATHNAME-COMPONENT-VALUE (version 1)
C00895 00167 ∂21-Mar-89 2227 CL-Cleanup-mailer Issue: PATHNAME-COMPONENT-VALUE (version 1)
C00897 00168 ∂22-Mar-89 1054 CL-Cleanup-mailer PRETTY-PRINT-INTERFACE, version 4
C00935 00169 ∂22-Mar-89 1057 CL-Cleanup-mailer PRETTY-PRINT-INTERFACE, version 4
C01000 00170 ∂22-Mar-89 1104 CL-Cleanup-mailer Issue: ADJUST-ARRAY-NOT-ADJUSTABLE (Version 9)
C01006 00171 ∂22-Mar-89 1612 CL-Cleanup-mailer Issue: PRETTY-PRINT-INTERFACE, version 4
C01008 00172 ∂22-Mar-89 2239 CL-Cleanup-mailer Issue: PATHNAME-SUBDIRECTORY-LIST (Version 4)
C01012 00173 ∂23-Mar-89 0645 CL-Cleanup-mailer Re: Issue: PATHNAME-COMPONENT-CASE (Version 2)
C01015 00174 ∂23-Mar-89 0804 CL-Cleanup-mailer Re: Issue: PATHNAME-COMPONENT-CASE (Version 2)
C01018 00175 ∂23-Mar-89 0805 CL-Cleanup-mailer Re: Issue: PATHNAME-SUBDIRECTORY-LIST (Version 4)
C01021 00176 ∂23-Mar-89 0820 CL-Cleanup-mailer Re: Issue: PATHNAME-COMPONENT-CASE (Version 2)
C01024 00177 ∂23-Mar-89 0919 CL-Cleanup-mailer Re: Issue: PATHNAME-COMPONENT-CASE (Version 2)
C01027 00178 ∂23-Mar-89 1112 CL-Cleanup-mailer Issue: PATHNAME-SUBDIRECTORY-LIST (Version 4)
C01030 00179 ∂23-Mar-89 1132 CL-Cleanup-mailer Issue: PATHNAME-SUBDIRECTORY-LIST (Version 4)
C01033 00180 ∂23-Mar-89 1205 CL-Cleanup-mailer string OK for :CONC-NAME in DEFSTRUCT?
C01036 00181 ∂23-Mar-89 1225 CL-Cleanup-mailer Meeting 1 hour before plenary session?
C01038 00182 ∂23-Mar-89 1504 CL-Cleanup-mailer Meeting 1 hour before plenary session?
C01040 00183 ∂23-Mar-89 1518 CL-Cleanup-mailer Issue: READ-CASE-SENSITIVITY (Version 2)
C01057 00184 ∂23-Mar-89 1534 CL-Cleanup-mailer Re: New cleanup issues
C01059 00185 ∂23-Mar-89 1538 CL-Cleanup-mailer Re: Issue: FIXNUM-NON-PORTABLE, v.5
C01068 00186 ∂23-Mar-89 1538 CL-Cleanup-mailer The Revised Cleanup Issue Status List
C01102 00187 ∂23-Mar-89 1656 CL-Cleanup-mailer Issue: READ-CASE-SENSITIVITY (Version 2)
C01106 00188 ∂23-Mar-89 1503 CL-Windows-mailer Issue STREAM-DEFINITION-BY-USER (V1)
C01149 00189 ∂23-Mar-89 1813 CL-Cleanup-mailer Re: Issue: READ-CASE-SENSITIVITY (Version 2)
C01152 00190 ∂23-Mar-89 1518 CL-Cleanup-mailer Issue: DIRECTORY-DOES-TOO-MUCH
C01159 00191 ∂23-Mar-89 1534 CL-Cleanup-mailer Re: Issue: GENSYM-NAME-STICKINESS (Version 3)
C01160 00192 ∂23-Mar-89 2050 CL-Cleanup-mailer Re: Issue: READ-CASE-SENSITIVITY (Version 2)
C01168 00193 ∂23-Mar-89 2232 CL-Cleanup-mailer Issue: DIRECTORY-DOES-TOO-MUCH
C01173 00194 ∂24-Mar-89 0745 CL-Cleanup-mailer Re: Issue: DIRECTORY-DOES-TOO-MUCH
C01176 00195 ∂24-Mar-89 0807 CL-Cleanup-mailer Meeting 1 hour before plenary session?
C01179 00196 ∂24-Mar-89 1015 CL-Cleanup-mailer Re: Issue: READ-CASE-SENSITIVITY (Version 2)
C01181 00197 ∂24-Mar-89 1024 CL-Cleanup-mailer Re: Issue: READ-CASE-SENSITIVITY (Version 2)
C01185 00198 ∂24-Mar-89 1344 CL-Cleanup-mailer Re: Issue: READ-CASE-SENSITIVITY (Version 2)
C01190 00199 ∂25-Mar-89 1209 CL-Cleanup-mailer Cleanup Meeting
C01192 00200 ∂29-Mar-89 1535 CL-Cleanup-mailer new version of LOAD-TRUENAME
C01202 00201 ∂29-Mar-89 1550 CL-Cleanup-mailer Issue: DESTRUCTURING-BIND, v.3
C01215 00202 ∂04-Apr-89 0804 CL-Cleanup-mailer Issue: ADJUST-ARRAY-NOT-ADJUSTABLE
C01216 00203 ∂04-Apr-89 0805 CL-Cleanup-mailer Issue: BREAK-ON-WARNINGS-OBSOLETE
C01218 00204 ∂04-Apr-89 0805 CL-Cleanup-mailer Issue: CLOS-CONDITIONS
C01219 00205 ∂04-Apr-89 0808 CL-Cleanup-mailer Issue: CLOS-MACRO-COMPILATION
C01221 00206 ∂04-Apr-89 0809 CL-Cleanup-mailer Issue: CLOSED-STREAM-OPERATIONS
C01223 00207 ∂04-Apr-89 0809 CL-Cleanup-mailer Issue: COERCE-INCOMPLETE
C01225 00208 ∂04-Apr-89 0816 CL-Cleanup-mailer Issue: COMMON-TYPE
C01226 00209 ∂04-Apr-89 0817 CL-Cleanup-mailer Issue: COMPILE-FILE-SYMBOL-HANDLING
C01228 00210 ∂04-Apr-89 0817 CL-Cleanup-mailer Issue: COMPILE-ENVIRONMENT-CONSISTENCY
C01230 00211 ∂04-Apr-89 0823 CL-Cleanup-mailer COMPILE-FILE-SYMBOL-HANDLING, COMPILE-ENVIRONMENT-CONSISTENCY
C01232 00212 ∂04-Apr-89 0832 CL-Cleanup-mailer Issue: COMPLEX-RATIONAL-RESULT
C01233 00213 ∂04-Apr-89 0833 CL-Cleanup-mailer Issue: CONDITION-RESTARTS
C01235 00214 ∂04-Apr-89 0834 CL-Cleanup-mailer Issue: COPY-SYMBOL-COPY-PLIST
C01236 00215 ∂04-Apr-89 0834 CL-Cleanup-mailer Issue: COPY-SYMBOL-COPY-PRINT-NAME
C01237 00216 ∂04-Apr-89 0835 CL-Cleanup-mailer Issue: DECLARE-FUNCTION-AMBIGUITY
C01239 00217 ∂04-Apr-89 0842 CL-Cleanup-mailer Issue: DEFINE-OPTIMIZER
C01241 00218 ∂04-Apr-89 0852 CL-Cleanup-mailer Issue: DEFMACRO-LAMBDA-LIST
C01243 00219 ∂04-Apr-89 0855 CL-Cleanup-mailer Issue: DEFMACRO-LAMBDA-LIST
C01246 00220 ∂04-Apr-89 0855 CL-Cleanup-mailer Issue: DESCRIBE-UNDERSPECIFIED
C01248 00221 ∂04-Apr-89 0857 CL-Cleanup-mailer Issue: DESTRUCTURING-BIND
C01250 00222 ∂04-Apr-89 1027 CL-Cleanup-mailer issue DYNAMIC-EXTENT-FUNCTION, version 1
C01256 00223 ∂04-Apr-89 1110 CL-Cleanup-mailer Issue: DYNAMIC-EXTENT
C01260 00224 ∂04-Apr-89 1111 CL-Cleanup-mailer Issue: EQUALP-GENERIC
C01261 00225 ∂04-Apr-89 1114 CL-Cleanup-mailer Issue: ERROR-CHECKING-IN-NUMBERS-CHAPTER
C01264 00226 ∂04-Apr-89 1115 CL-Cleanup-mailer Issue: ERROR-NOT-HANDLED
C01266 00227 ∂04-Apr-89 1117 CL-Cleanup-mailer Issue: FUNCTION-COERCE-TIME
C01267 00228 ∂04-Apr-89 1125 CL-Cleanup-mailer Issue: EXIT-EXTENT
C01269 00229 ∂04-Apr-89 1127 CL-Cleanup-mailer Re: Issue: DYNAMIC-EXTENT
C01272 00230 ∂04-Apr-89 1127 CL-Cleanup-mailer Issue: FUNCTION-NAME
C01275 00231 ∂04-Apr-89 1133 CL-Cleanup-mailer Re: Issue: DYNAMIC-EXTENT
C01277 00232 ∂04-Apr-89 1133 CL-Cleanup-mailer Issue: GENSYM-NAME-STICKINESS
C01279 00233 ∂04-Apr-89 1147 CL-Cleanup-mailer Issue: HASH-TABLE-ACCESS
C01282 00234 ∂04-Apr-89 1148 CL-Cleanup-mailer Issue: HASH-TABLE-SIZE
C01284 00235 ∂04-Apr-89 1149 CL-Cleanup-mailer Issue: IN-PACKAGE-FUNCTIONALITY
C01287 00236 ∂04-Apr-89 1153 CL-Cleanup-mailer Issue: IN-SYNTAX
C01290 00237 ∂04-Apr-89 1156 CL-Cleanup-mailer Issue: LISP-PACKAGE-NAME
C01292 00238 ∂04-Apr-89 1200 CL-Cleanup-mailer Issue: LISP-SYMBOL-REDEFINITION
C01295 00239 ∂04-Apr-89 1206 CL-Cleanup-mailer Issue: LOAD-OBJECTS (Version 4)
C01318 00240 ∂04-Apr-89 1217 CL-Cleanup-mailer Issue: LOAD-TRUENAME
C01322 00241 ∂04-Apr-89 1219 CL-Cleanup-mailer Issue: LOCALLY-TOP-LEVEL
C01324 00242 ∂04-Apr-89 1219 CL-Cleanup-mailer Issue: LOOP-AND-DISCREPANCY
C01325 00243 ∂04-Apr-89 1221 CL-Cleanup-mailer Issue: MACRO-ENVIRONMENT-EXTENT
C01327 00244 ∂04-Apr-89 1221 CL-Cleanup-mailer Issue: MAKE-STRING-FILL-POINTER
C01329 00245 ∂04-Apr-89 1222 CL-Cleanup-mailer Issue: PACKAGE-FUNCTION-CONSISTENCY
C01331 00246 ∂04-Apr-89 1226 CL-Cleanup-mailer Issue: PATHNAME-LOGICAL
C01333 00247 ∂04-Apr-89 1227 CL-Cleanup-mailer Issue: PATHNAME-PRINT-READ
C01335 00248 ∂04-Apr-89 1227 CL-Cleanup-mailer Issue: PATHNAME-CANONICAL-TYPE
C01337 00249 ∂04-Apr-89 1231 CL-Cleanup-mailer Issue: PATHNAME-SUBDIRECTORY-LIST
C01338 00250 ∂04-Apr-89 1232 CL-Cleanup-mailer Issue: PEEK-CHAR-READ-CHAR-ECHO
C01340 00251 ∂04-Apr-89 1233 CL-Cleanup-mailer Issue: PRETTY-PRINT-INTERFACE
C01341 00252 ∂04-Apr-89 1235 CL-Cleanup-mailer Issue: PATHNAME-COMPONENT-CASE
C01343 00253 ∂04-Apr-89 1238 CL-Cleanup-mailer Issue: PROCLAIM-LEXICAL
C01346 00254 ∂04-Apr-89 1238 CL-Cleanup-mailer Issue: READ-CASE-SENSITIVITY
C01348 00255 ∂04-Apr-89 1240 CL-Cleanup-mailer Issue: READ-DELIMITED-LIST-EOF
C01350 00256 ∂04-Apr-89 1242 CL-Cleanup-mailer Issue: REMF-DESTRUCTION-UNSPECIFIED (Version 6)
C01352 00257 ∂04-Apr-89 1244 CL-Cleanup-mailer Issue: PATHNAME-COMPONENT-VALUE
C01353 00258 ∂04-Apr-89 1244 CL-Cleanup-mailer Issue: SETF-MULTIPLE-STORE-VARIABLES
C01355 00259 ∂04-Apr-89 1249 CL-Cleanup-mailer Issue: SYMBOL-MACROLET-SEMANTICS
C01358 00260 ∂04-Apr-89 1249 CL-Cleanup-mailer Issue: THE-AMBIGUITY
C01359 00261 ∂04-Apr-89 1252 CL-Cleanup-mailer Issue: TIME-ZONE-NON-INTEGER
C01362 00262 ∂04-Apr-89 1253 CL-Cleanup-mailer Issue: PATHNAME-SYNTAX-ERROR-TIME
C01363 00263 ∂04-Apr-89 1256 CL-Cleanup-mailer Issue: PATHNAME-WILD
C01364 00264 ∂04-Apr-89 1258 CL-Cleanup-mailer Issue: WITH-COMPILATION-UNIT
C01366 00265 ∂04-Apr-89 1301 CL-Cleanup-mailer Issue: PRINT-CASE-PRINT-ESCAPE-INTERACTION
C01368 00266 ∂04-Apr-89 1301 CL-Cleanup-mailer Issue: EXIT-EXTENT (version 7)
C01393 00267 ∂04-Apr-89 1301 CL-Cleanup-mailer Issue: PRINT-CIRCLE-SHARED
C01395 00268 ∂04-Apr-89 1304 CL-Cleanup-mailer Issue: REAL-NUMBER-TYPE
C01397 00269 ∂04-Apr-89 1309 CL-Cleanup-mailer Issue: REQUIRE-PATHNAME-DEFAULTS
C01400 00270 ∂04-Apr-89 1309 CL-Cleanup-mailer Issue: UNDEFINED-VARIABLES-AND-FUNCTIONS
C01402 00271 ∂04-Apr-89 1309 CL-Cleanup-mailer Issue: TYPE-OF-UNDERCONSTRAINED
C01404 00272 ∂04-Apr-89 1324 CL-Cleanup-mailer issue DYNAMIC-EXTENT-FUNCTION, version 1
C01411 00273 ∂04-Apr-89 1531 CL-Cleanup-mailer Issue: COPY-SYMBOL-PRINT-NAME (not COPY-SYMBOL-COPY-PRINT-NAME)
C01413 00274 ∂04-Apr-89 2058 CL-Cleanup-mailer issue DYNAMIC-EXTENT-FUNCTION, version 1
C01419 00275 ∂05-Apr-89 0710 CL-Cleanup-mailer Re: issue DYNAMIC-EXTENT-FUNCTION, version 1
C01423 00276 ∂05-Apr-89 0721 CL-Cleanup-mailer Re: issue DYNAMIC-EXTENT-FUNCTION, version 1
C01426 00277 ∂05-Apr-89 0805 CL-Cleanup-mailer Re: Issue: LISP-SYMBOL-REDEFINITION
C01428 00278 ∂05-Apr-89 0848 CL-Cleanup-mailer issue DYNAMIC-EXTENT-FUNCTION, version 1
C01430 00279 ∂05-Apr-89 1159 CL-Cleanup-mailer Issue: DYNAMIC-EXTENT (Version 4)
C01449 00280 ∂05-Apr-89 1206 CL-Cleanup-mailer Issue: DYNAMIC-EXTENT (Version 4)
C01451 00281 ∂05-Apr-89 1731 CL-Cleanup-mailer issue DYNAMIC-EXTENT-FUNCTION, version 1
C01454 00282 ∂05-Apr-89 2203 CL-Cleanup-mailer issue DYNAMIC-EXTENT-FUNCTION, version 1
C01457 00283 ∂06-Apr-89 1115 CL-Cleanup-mailer Condensed summary of CL Cleanup meeting results
C01472 00284 ∂09-Apr-89 0921 CL-Cleanup-mailer Issue COMPLEX-RATIONAL-RESULT, version 2
C01480 00285 ∂09-Apr-89 2155 CL-Cleanup-mailer Issue: LISP-SYMBOL-REDEFINITION, v.6
C01489 00286 ∂09-Apr-89 2239 CL-Cleanup-mailer Re: Issue: PACKAGE-FUNCTION-CONSISTENCY
C01491 00287 ∂09-Apr-89 2248 CL-Cleanup-mailer Re: Issue: PATHNAME-CANONICAL-TYPE (Version 1)
C01493 00288 ∂09-Apr-89 2315 CL-Cleanup-mailer Re: PRETTY-PRINT-INTERFACE, version 4
C01495 00289 ∂09-Apr-89 2332 CL-Cleanup-mailer Issue: READ-DELIMITED-LIST-EOF
C01499 00290 ∂10-Apr-89 0006 CL-Cleanup-mailer Re: Issue: TYPE-OF-UNDERCONSTRAINED
C01501 00291 ∂10-Apr-89 0028 CL-Cleanup-mailer Cleanup Issue status, 10-Apr-89
C01536 00292 ∂10-Apr-89 1025 CL-Cleanup-mailer Cleanup Issue status, 10-Apr-89
C01571 00293 ∂10-Apr-89 1303 CL-Cleanup-mailer Issue: LOAD-TRUENAME (Version 3)
C01582 00294 ∂10-Apr-89 1349 CL-Cleanup-mailer Issue: LOAD-TRUENAME (Version 3)
C01585 00295 ∂10-Apr-89 1621 CL-Cleanup-mailer Issue: PATHNAME-CANONICAL-TYPE
C01594 00296 ∂11-Apr-89 0714 CL-Cleanup-mailer Issue: LOAD-TRUENAME (Version 4)
C01606 00297 ∂11-Apr-89 2155 CL-Cleanup-mailer Re: Issue: PATHNAME-CANONICAL-TYPE
C01610 00298 ∂12-Apr-89 1012 CL-Cleanup-mailer issue PRETTY-PRINT-INTERFACE
C01613 00299 ∂14-Apr-89 0700 CL-Cleanup-mailer Status of CL Condition Handling
C01623 00300 ∂17-Apr-89 1301 CL-Cleanup-mailer [Robert S. Boyer <boyer@CLI.COM>: Fast IO]
C01629 00301 ∂19-Apr-89 0707 CL-Cleanup-mailer [Robert S. Boyer <boyer@CLI.COM>: Fast IO]
C01632 00302 ∂19-Apr-89 1519 CL-Cleanup-mailer no :in-file
C01634 00303 ∂19-Apr-89 1528 CL-Cleanup-mailer [Robert S. Boyer <boyer@CLI.COM>: Fast IO]
C01637 00304 ∂19-Apr-89 1557 CL-Cleanup-mailer no :in-file
C01639 00305 ∂19-Apr-89 1621 CL-Cleanup-mailer no :in-file
C01642 00306 ∂20-Apr-89 1454 CL-Cleanup-mailer Issue: THE-VALUES [was: intent of (THE <type> <expression>)]
C01645 00307 ∂20-Apr-89 2003 CL-Cleanup-mailer Issue: ERROR-TERMINOLOGY (final amended version ??? Version 9)
C01650 ENDMK
C⊗;
∂13-Mar-89 1254 CL-Cleanup-mailer amendments to already passed issues
Received: from Think.COM by SAIL.Stanford.EDU with TCP; 13 Mar 89 12:54:30 PST
Received: from fafnir.think.com by Think.COM; Mon, 13 Mar 89 15:50:47 EST
Return-Path: <gls@Think.COM>
Received: from verdi.think.com by fafnir.think.com; Mon, 13 Mar 89 15:52:12 EST
Received: by verdi.think.com; Mon, 13 Mar 89 15:49:01 EST
Date: Mon, 13 Mar 89 15:49:01 EST
From: Guy Steele <gls@Think.COM>
Message-Id: <8903132049.AA02739@verdi.think.com>
To: Moon@stony-brook.scrc.symbolics.com
Cc: gls@Think.COM, cl-cleanup@sail.stanford.edu
In-Reply-To: David A. Moon's message of Sat, 11 Mar 89 17:50 EST <19890311225011.1.MOON@EUPHRATES.SCRC.Symbolics.COM>
Subject: amendments to already passed issues
Date: Sat, 11 Mar 89 17:50 EST
From: David A. Moon <Moon@stony-brook.scrc.symbolics.com>
...
I'm glad -somebody- is double-checking already passed issues. Also I'm
glad that -you- are.
Thanks for the compliment. Maybe someday I will have atoned for ~:{ ~:↑ ~}.
--Quux
∂13-Mar-89 1352 CL-Cleanup-mailer Issue: LOAD-OBJECTS (Version 3)
Received: from Sun.COM by SAIL.Stanford.EDU with TCP; 13 Mar 89 13:51:55 PST
Received: from snail.Sun.COM by Sun.COM (4.1/SMI-4.0)
id AA16534; Mon, 13 Mar 89 11:37:16 PST
Received: from lukasiewicz.sun.com by snail.Sun.COM (4.1/SMI-4.0)
id AA20771; Mon, 13 Mar 89 11:32:38 PST
Received: by lukasiewicz.sun.com (4.0/SMI-4.0)
id AA00318; Mon, 13 Mar 89 11:35:38 PST
Date: Mon, 13 Mar 89 11:35:38 PST
From: jrose@Sun.COM (John Rose)
Message-Id: <8903131935.AA00318@lukasiewicz.sun.com>
To: sandra%defun@cs.utah.edu
Cc: rpg@lucid.com, CL-Cleanup@sail.stanford.edu, CL-Compiler@sail.stanford.edu,
Common-Lisp-Object-System@sail.stanford.edu
In-Reply-To: Sandra J Loosemore's message of Sat, 11 Mar 89 18:42:56 MST <8903120142.AA00878@defun.utah.edu>
Subject: Issue: LOAD-OBJECTS (Version 3)
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Date: Sat, 11 Mar 89 18:42:56 MST
...
Have two generic functions, not one. The first would get called by
compile-file and it would return a list of components (or whatever)
that are required to reconstruct the object. The compiler would dump
this list of objects in its usual way. The loader would apply the
second generic function to this list to reconstruct the object. It
avoids the nasty syntax you object to, doesn't require functions to be
dumpable, doesn't require any special support for circular constants,
and ought to be real easy to add to the compiler/loader. (You could
essentially convert the constant into a LOAD-TIME-VALUE expression.)
Two objections here:
One is that this scheme cannot support circular constants. Since
LOAD-OBJECTS is not the issue which determines circular constants, it
probably should not force or presuppose a decision against circular
constants.
Supporting circular constants requires two phases of object
construction, one which creates at least a valid reference to the
object, and a second one which further initializes the object (at least
by patching in back-references to finish building circularities).
In order for your technique to support circular constants, you still
need #'make-load-form to return two things, not one. It would return
two argument lists, and there would be two load-time generic functions.
The other objection is that an arglist for a fixed generic function is
less general and more complex than an EVAL-able form (or a thunk, as rpg
suggests). The programmer must coordinate the construction of the
argument list with the definition of the method to digest it at load
time, which is probably on a different page of the source code. What's
the advantage to offset the complexity and lack of flexibility?
Perhaps method combination within the load-time generic gives a clean
way to modularize the construction of an object of multiple classes?
Someone will have to show me an example of this before I believe it.
Until then, I think the simplicity of thunks (either EVAL-able or
FUNCALL-able) is far preferable.
By the way, I also share rpg's preference for functions over forms,
because functions are parametrized naturally via captured lexicals,
whereas you've got to use backquote to parametrize forms, a more
error-prone technique.
Here's an example which suggests the relative conciseness of the techniques:
;; Using functions:
(defmethod make-load-form ((x myclass))
(let ((p <pval>) (q <qval>) (r <rval>))
#'(lambda () <code>)))
;; Using forms:
(defmethod make-load-form ((x myclass))
`(let ((p ',<pval>) (q ',<qval>) (r ',<rval>))
<code>))
;; Using a generic:
(defmethod make-load-form ((x myclass))
`(cookie00012 :p ,<pval> :q ,<qval> :r ,<rval>))
(defmethod load-time-constructor
((lf (eql 'cookie00012)) &key p q r &allow-other-keys)
<code>)
-Sandra
-------
-- John
∂13-Mar-89 1448 CL-Cleanup-mailer Issue: LOAD-TRUENAME (Version 1)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 13 Mar 89 14:48:09 PST
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 556116; Mon 13-Mar-89 17:45:37 EST
Date: Mon, 13 Mar 89 17:45 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: LOAD-TRUENAME (Version 1)
To: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <890313174517.3.KMP@BOBOLINK.SCRC.Symbolics.COM>
This one was kind of on the table (due to Touretzky), but never got
written up formally. I think it's important, so I'll risk getting yelled
at by sending it out `new' at the last minute...
-----
Issue: LOAD-TRUENAME
Forum: Cleanup
References: LOAD (p426), PROVIDE (p188), REQUIRE (p188),
Issue REQUIRE-PATHNAME-DEFAULTS
Category: ADDITION
Edit history: 13-Mar-89, Version 1 by Pitman
Status: For Internal Discussion
Problem Description:
It is difficult to construct sets of software modules which work
together as a unit and which port between different implementations.
REQUIRE and PROVIDE were intended to provide this level of support
but have `failed' to be portable in practice.
Typical user configurations involve a `system definition' file which
loads the modules of a `system' (collection of software modules).
Among the specific problems which arise are:
- File system types may vary. Different file syntax must be used for
each site.
- Even with the same Lisp implementation and host file system type,
the directory in which a software system resides may differ from
delivery site to delivery site.
- Multiple `copies' of the same system may reside in different
directories on the same machine.
Proposal (LOAD-TRUENAME:NEW-PATHNAME-VARIABLES):
Introduce new variables:
*LOAD-TRUENAME* [Variable]
This special variable is initially NIL, but is bound by LOAD to
hold the truename of the pathname of the file being loaded.
*COMPILE-FILE-TRUENAME* [Variable]
This special variable is initially NIL, but is bound by
COMPILE-FILE to hold the truename of the pathname of the file
being compiled.
Example:
------ File SETUP ------
(IN-PACKAGE 'MY-STUFF)
(DEFMACRO COMPILE-TRUENAME () `',*COMPILE-FILE-TRUENAME*)
(DEFVAR *SOURCE-FILE* (COMPILE-TRUENAME) "Just for debugging.")
(DEFVAR *LOADED-FILE* *LOAD-TRUENAME*)
(DEFUN LOAD-MY-SYSTEM ()
(DOLIST (MODULE-NAME '("FOO" "BAR" "BAZ"))
(LOAD (MERGE-PATHNAMES MODULE-NAME *LOAD-TRUENAME*))))
------------------------
(LOAD "SETUP")
(LOAD-MY-SYSTEM)
Rationale:
This satisfies the most common instances of the frequently reported
problem in the Problem Description.
Current Practice:
Wide variation.
In some implementations, calling LOAD binds or sets
*DEFAULT-PATHNAME-DEFAULTS* so that pathnames named in a file being
LOADed will default to being `nearby.'
Some implementations provide special variables that are similar or
identical to one or both of those proposed.
Some implementations have a way to represent the pathname for the
current working directory, and make the default pathname default
to that, so that loading without specifying a default again tends to
get `nearby' files.
None of these techniques is portable, unfortunately, because there
is no agreement.
Cost to Implementors:
Very small.
Cost to Users:
None. This change is upward compatible.
Cost of Non-Adoption:
Continued difficulty for anyone trying to put a system of modules
in a form where they can be conveniently delivered using portable code.
Benefits:
The cost of non-adoption is avoided.
Aesthetics:
Negligible.
Discussion:
Touretzky raised the issue most recently on Common-Lisp. A number
of people immediately jumped on the bandwagon, indicating it was
important to them, too.
Pitman made three suggestions in response, of which the above is
the first. The others included:
2. Variables *LOAD-TRUENAMES* and *COMPILE-FILE-TRUENAMES* which hold
lists of the truenames of all files being loaded or compiled,
respectively, during the dynamic invocation of LOAD and COMPILE-FILE.
3. Variable *LOAD-OR-COMPILE-FILE-TRUENAMES* which holds a list like
((LOAD truename) (COMPILE-FILE truename) ...)
during the dynamic invocation of LOAD and COMPILE-FILE.
Touretzky responded:
``I like KMP's proposals. I like the second one best: have separate
variables for files being loaded and files being compiled, and use
them to maintain a stack so we can see the nesting of loads within
files.''
Pitman ultimately chose to present the first rather than the second
because it seemed simpler, easier to explain, and more likely to
pass at this late date.
∂13-Mar-89 1457 CL-Cleanup-mailer Issue CLOS-CONDITIONS, v4
Received: from ECLC.USC.EDU by SAIL.Stanford.EDU with TCP; 13 Mar 89 14:57:13 PST
Date: Sat 11 Mar 89 19:32:37-PST
From: Kim A. Barrett <IIM%ECLA@ECLC.USC.EDU>
Subject: Issue CLOS-CONDITIONS, v4
To: kmp@SCRC-STONY-BROOK.ARPA
cc: cl-cleanup@SAIL.STANFORD.EDU, iim%ECLA@ECLC.USC.EDU
Message-ID: <12477306674.30.IIM@ECLA.USC.EDU>
I would like to second Richard Mlynarik's suggestion of a REPORT-CONDITION
method, for much the same reasons he mentioned. It's really ugly to have to
always include the check for *PRINT-ESCAPE* with a CALL-NEXT-METHOD every time
you want to define your own report method for a condition.
kab
-------
∂13-Mar-89 1457 CL-Cleanup-mailer gls cleanups
Received: from ECLC.USC.EDU by SAIL.Stanford.EDU with TCP; 13 Mar 89 14:57:49 PST
Date: Sun 12 Mar 89 16:03:32-PST
From: Kim A. Barrett <IIM%ECLA@ECLC.USC.EDU>
Subject: gls cleanups
To: gls@THINK.COM
cc: cl-cleanup@SAIL.STANFORD.EDU, iim%ECLA@ECLC.USC.EDU
Message-ID: <12477530754.30.IIM@ECLA.USC.EDU>
> (2) SYMBOL-MACROLET-SEMANTICS should perhaps also specify that PSETQ of a
> symbol-macro symbol behaves like PSETF.
This probably isn't strictly necessary. PSETQ is a macro which presumably
expands into code which uses SETQ (assuming it doesn't expand into code which
uses an implementation-specific special form), which will then be transformed
into SETF. MULTIPLE-VALUE-SETQ is similar. Of course, it might be easier for
a compiler to optimize a PSETF than the transformed PSETQ expansion.
kab
-------
∂13-Mar-89 1500 CL-Cleanup-mailer Issue ERROR-CHECKING-IN-NUMBERS-CHAPTER
Received: from ECLC.USC.EDU by SAIL.Stanford.EDU with TCP; 13 Mar 89 15:00:48 PST
Date: Sun 12 Mar 89 16:01:13-PST
From: Kim A. Barrett <IIM%ECLA@ECLC.USC.EDU>
Subject: Issue ERROR-CHECKING-IN-NUMBERS-CHAPTER
To: kmp@SCRC-STONY-BROOK.ARPA
cc: cl-cleanup@SAIL.STANFORD.EDU, iim%ECLA@ECLC.USC.EDU
Message-ID: <12477530332.30.IIM@ECLA.USC.EDU>
The question of whether NaNs and such cause TYPE-ERROR or ARITHMETIC-ERROR is
what I feel unsure about. We currently signal ARITHMETIC-ERROR, but I don't
believe there was a lot of analysis that went into that decision. I think
that any decision we make on this is likely to be pretty arbitrary. I can't
think of any strong first-principled arguments either way, so it may be a
matter of which seems more convenient to the people who really care about
an error being signaled for such things.
kab
-------
∂13-Mar-89 1501 CL-Cleanup-mailer Issue SUBTYPEP-TOO-VAGUE
Received: from ECLC.USC.EDU by SAIL.Stanford.EDU with TCP; 13 Mar 89 15:01:01 PST
Date: Sun 12 Mar 89 16:05:04-PST
From: Kim A. Barrett <IIM%ECLA@ECLC.USC.EDU>
Subject: Issue SUBTYPEP-TOO-VAGUE
To: cl-cleanup@SAIL.STANFORD.EDU
cc: iim%ECLA@ECLC.USC.EDU
Message-ID: <12477531034.30.IIM@ECLA.USC.EDU>
> I don't see any problem here. My compiler has a type testing function
> that handles VALUES types itself and converts (FUNCTION ...) to just
> FUNCTION before calling SUBTYPEP, so it isn't prevented from doing anything
> that it wants.
And what does it do with a deftype'ed type which expands into a list form
FUNCTION type specifier or into a VALUES type specifier? Did you remember to
call type-expand before doing the conversion? Note that a user wouldn't be
able to do that, since type-expand isn't part of the language. And what about
an OR of several FUNCTION or VALUES type specifiers? Besides, it's wrong to
have to define the handling of the VALUES type yourself, even ignoring these
problems, since you end up with each user who wants this capability having to
write his own, rather than having the facility built into SUBTYPEP where it
belongs.
> If you want these cases to be permitted, then you will need to define what
> they mean.
Thats an ugly job. One of us was working on it, but hasn't had much time to
devote to the problem -- probably nobody here at IIM will be able to get to
it any time soon. Right now we mostly just don't want these to be required
signal error cases, with the intention of fully specifying them later.
(Note: some of the ugliness involves questions about what to do when the
typed lambda-lists aren't congruent (in the CLOS sense)).
kab
-------
∂13-Mar-89 1502 CL-Cleanup-mailer Issue PEEK-CHAR-READ-CHAR-ECHO
Received: from ECLC.USC.EDU by SAIL.Stanford.EDU with TCP; 13 Mar 89 15:01:49 PST
Date: Sun 12 Mar 89 16:09:23-PST
From: Kim A. Barrett <IIM%ECLA@ECLC.USC.EDU>
Subject: Issue PEEK-CHAR-READ-CHAR-ECHO
To: kmp@SCRC-STONY-BROOK.ARPA
cc: cl-cleanup@SAIL.STANFORD.EDU, iim%ECLA@ECLC.USC.EDU
Message-ID: <12477531820.30.IIM@ECLA.USC.EDU>
The whole discussion of operating system considerations in the proposal just
confuses the issue, and isn't relevent to what the actual proposal says, so
that's a problem with the proposal. It may have lead some people to vote for
it because they got confused into thinking that the operating system
considerations were relevent. Note that I may have fallen into this trap.
When I wrote the example, I was thinking in terms of a reader that used
read-char/unread-char, rather than peek-char. Looking at the proposal again,
I note that it mentions the reader.
However, I think the discussion of the cost of this proposal is pretty weak.
First, an implication of the proposal is that peek-char is no longer
equivelent to read-char followed by unread-char. This means that all code
which uses read-char/unread-char needs to be re-examined, and probably
modified. That's a potentially large amount of code, due to the performance
effect that is not mentioned at all in the proposal. Namely, it is frequently
the case when parsing input that you get stretches where all the characters
are going to be used.
An example might be a reader's subroutine for reading an extended token. If
the two forms of 'peeking' are equivelent, then the token reader can iterate
on read-char until it finds a terminator, unreads it, and proceeds. Under
this proposal, it has to iterate on peek-char, decide if it likes it, and if
so then read-char to really get it. For such important subroutines in the
reader as the token reader, the string reader, the whitespace scanner, and
similar functions, this could mean something on the order of a factor of 2
performance hit. Slowing down important parts of the reader by a factor of
2 is not likely to make anyone smile (except those C lovers out there :-).
We're not advocating that it be left vague. I should have taken the time to
present our counter-proposal, but I was in a hurry, and I've had this note on
my desk to do something about this issue for over a month now, so I didn't.
Foolish me.
Our position is that LAST-READ-CHAR is the proper behavior, with an additional
restriction that it is an error to do output to a stream between the calls to
read and unread. As a hint, here is how we've implemented this behavior.
1. Define two operations on streams, ECHO and UNECHO.
2. echo-streams, when reading a character, apply echo to the output stream and
the character. unread on echo-streams calls unecho on the output stream
and char, in addition to passing along the unread to the input stream.
3. Other meta-streams simply pass these operations along to their output side.
4. data-streams have two choices, depending on whether they have the
capability to 'back out' output. If they can back it out, then echo is
equivilent to write-char, and unecho backs it out. If they can't, then
they record the echo in a slot, writing any already pending echo. unecho
clears the pending echo slot. all normal output operations first write
pending echo. a normal close also forces pending echoing.
There is potentially more hair involved, intended to either support or
complain about improper usage, like calling unread after peek, doing output
between the read and the unread, &etc. Note that this depends on the single
unread restriction in order to work right in all cases.
kab
-------
∂13-Mar-89 1457 CL-Compiler-mailer Issue LOCALLY-TOP-LEVEL, v1
Received: from ECLC.USC.EDU by SAIL.Stanford.EDU with TCP; 13 Mar 89 14:57:25 PST
Date: Sat 11 Mar 89 19:34:07-PST
From: Kim A. Barrett <IIM%ECLA@ECLC.USC.EDU>
Subject: Issue LOCALLY-TOP-LEVEL, v1
To: Moon@SCRC-STONY-BROOK.ARPA
cc: cl-cleanup@SAIL.STANFORD.EDU, cl-compiler@SAIL.STANFORD.EDU,
iim%ECLA@ECLC.USC.EDU
Message-ID: <12477306947.30.IIM@ECLA.USC.EDU>
This issue arguably ought to be a compiler issue, rather than cleanup, since
the compiler people seem to be the ones currently mucking about with what we
mean by top-level. (Besides, Larry is overworked as it is :-)
More seriously, I support this idea, in part because of the frob example. This
kind of thing was one of the reasons I voted against the DECLARATION-SCOPE
proposals.
By the way, my notes from the Hawaii meeting say that we passed the NO-HOISTING
proposal, and that LIMITED-HOISTING was not even called to a vote.
kab
-------
∂13-Mar-89 1557 CL-Cleanup-mailer Issue LOCALLY-TOP-LEVEL, v1
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 13 Mar 89 15:55:08 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 556199; Mon 13-Mar-89 18:51:17 EST
Date: Mon, 13 Mar 89 18:51 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue LOCALLY-TOP-LEVEL, v1
To: Kim A. Barrett <IIM%ECLA@ECLC.USC.EDU>
cc: cl-cleanup@SAIL.STANFORD.EDU, cl-compiler@SAIL.STANFORD.EDU
In-Reply-To: <12477306947.30.IIM@ECLA.USC.EDU>
Message-ID: <19890313235118.7.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Sat 11 Mar 89 19:34:07-PST
From: Kim A. Barrett <IIM%ECLA@ECLC.USC.EDU>
This issue arguably ought to be a compiler issue, rather than cleanup, since
the compiler people seem to be the ones currently mucking about with what we
mean by top-level. (Besides, Larry is overworked as it is :-)
I may have sent it to the wrong committee by mistake. If either Sandra or
Larry instructs me to send it to the other committee, I'll do so forthwith.
More seriously, I support this idea, in part because of the frob example. This
kind of thing was one of the reasons I voted against the DECLARATION-SCOPE
proposals.
By the way, my notes from the Hawaii meeting say that we passed the NO-HOISTING
proposal, and that LIMITED-HOISTING was not even called to a vote.
You're right, I copied down the wrong proposal name. What I said about
it is true of the NO-HOISTING proposal but false of the LIMITED-HOISTING
proposal. This needs to be fixed before it's distributed more widely.
∂13-Mar-89 1726 CL-Cleanup-mailer Re: issue PROCLAIM-LEXICAL (Version 9)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 13 Mar 89 17:26:13 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 13 MAR 89 17:14:49 PST
Date: 13 Mar 89 17:14 PST
From: masinter.pa@Xerox.COM
Subject: Re: issue PROCLAIM-LEXICAL (Version 9)
In-reply-to: Jeff Dalton <jeff%aiai.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK>'s
message of Mon, 13 Feb 89 20:34:53 GMT
To: cl-cleanup@sail.stanford.edu
Message-ID: <890313-171449-21261@Xerox>
I'm finally getting back to doing some cleanup work, after a long hiatus.
The last version of PROCLAIM-LEXICAL I have is Version 9, which was
distributed before the Hawaii meeting. There were the various comments on
Version 9, amendments proposed but not passed, and, more recently, mail
from Sandra Loosemore, Jeff Dalton, JonL White, Gail Zacharias and David
Moon.
However, there's no new version.
Who will produce one? If we don't have a new version, we probably won't be
able to vote on anything.
I think that would be a shame.
Larry
∂13-Mar-89 1737 CL-Compiler-mailer Re: Issue: LOAD-OBJECTS (Version 3)
Received: from ti.com by SAIL.Stanford.EDU with TCP; 13 Mar 89 17:36:36 PST
Received: by ti.com id AA04345; Mon, 13 Mar 89 19:33:22 CST
Received: from Kelvin by tilde id AA09130; Mon, 13 Mar 89 19:25:26 CST
Message-Id: <2814830669-4406064@Kelvin>
Sender: GRAY@Kelvin.csc.ti.com
Date: Mon, 13 Mar 89 19:24:29 CST
From: David N Gray <Gray@DSG.csc.ti.com>
To: "Richard P. Gabriel" <rpg@lucid.com>
Cc: CL-Cleanup@sail.stanford.edu, CL-Compiler@sail.stanford.edu
Subject: Re: Issue: LOAD-OBJECTS (Version 3)
In-Reply-To: Msg of Sat, 11 Mar 89 16:46:51 PST from Richard P. Gabriel <rpg@lucid.com>
> I was a little surprised to see that this proposal talks about load
> forms instead of load functions (which goes to show how much I've been
> paying attention).
One advantage of sticking with the load form approach is that it has
already been implemented and demonstrated to work.
> I think people will find the macro approach (the current approach)
> baroque, partly because the approach is best understood by thinking of
> an input phase to a compiler or some such program, rather than by
> thinking about an output phase when everything has already been supposedly
> created. For example, when I read the current proposal, I imagined it
> in the FASDUMP phase.
Think of it as input to the loader.
> One drawback of my proposal is that the function approach is a little
> more verbose in some cases. I also think it is subject to more
> circularity errors by novices than the macro approach. On the other
> hand, the functional approach makes one think about the issues a
> little harder when writing the code, which is possibly a good thing.
This sounds like a clear disadvantage, without a clear advantage.
> ;; Example 3 (expanded to do a hairy thing that cannot be easily done
> ;; in the macro approach).
...
> One can imagine the shared lexical environment of the creator and initializer
> being a high-bandwidth channel for information, such as the important
> information passed in the above example.
This example illustrates the following assumptions about dumping
constants:
1. Lexical closures can be dumped and loaded.
2. Two closures that share the same environment at compile-time will
also share the same environment at load time.
3. The lexical environment as reconstructed by the loader is not
write-protected (meaning that closures are not really constants).
4. It is safe to assume that none of the closed-over variables are
changed between the time the first closure is dumped and the time
the last closure that shares that environment is dumped.
It could be argued that all of these would be desirable, but I think
it's a little late to be biting off that much.
∂13-Mar-89 1754 CL-Compiler-mailer Re: Issue: LOAD-OBJECTS (Version 3)
Received: from ti.com by SAIL.Stanford.EDU with TCP; 13 Mar 89 17:54:05 PST
Received: by ti.com id AA04437; Mon, 13 Mar 89 19:49:49 CST
Received: from Kelvin by tilde id AA09309; Mon, 13 Mar 89 19:36:34 CST
Message-Id: <2814831335-4446073@Kelvin>
Sender: GRAY@Kelvin.csc.ti.com
Date: Mon, 13 Mar 89 19:35:35 CST
From: David N Gray <Gray@DSG.csc.ti.com>
To: jrose@Sun.COM (John Rose)
Cc: sandra%defun@cs.utah.edu, rpg@lucid.com, CL-Cleanup@sail.stanford.edu,
CL-Compiler@sail.stanford.edu
Subject: Re: Issue: LOAD-OBJECTS (Version 3)
In-Reply-To: Msg of Mon, 13 Mar 89 11:35:38 PST from jrose@Sun.COM (John Rose)
> One is that this scheme cannot support circular constants.
I second the objection.
> By the way, I also share rpg's preference for functions over forms,
> because functions are parametrized naturally via captured lexicals,
> whereas you've got to use backquote to parametrize forms, a more
> error-prone technique.
>
> Here's an example which suggests the relative conciseness of the techniques:
>
> ;; Using functions:
> (defmethod make-load-form ((x myclass))
> (let ((p <pval>) (q <qval>) (r <rval>))
> #'(lambda () <code>)))
>
> ;; Using forms:
> (defmethod make-load-form ((x myclass))
> `(let ((p ',<pval>) (q ',<qval>) (r ',<rval>))
> <code>))
I don't think that's a completely fair comparison because the LET is
required for the function approach, but would usually not be needed with
the forms approach:
;; Using functions:
(defmethod make-load-form ((x myclass))
(let ((p <pval>) (q <qval>) (r <rval>))
#'(lambda () (make-mine p q r))))
;; Using forms:
(defmethod make-load-form ((x myclass))
`(make-mine ',<pval> ',<qval> ',<rval>))
This is a very simple use of back-quote, while the function approach is
error-prone because it would be too easy to forget to do the LET
binding.
∂14-Mar-89 0738 CL-Cleanup-mailer Re: Issue PEEK-CHAR-READ-CHAR-ECHO
Received: from RELAY.CS.NET by SAIL.Stanford.EDU with TCP; 14 Mar 89 07:38:43 PST
Received: from relay2.cs.net by RELAY.CS.NET id ac25715; 14 Mar 89 10:16 EST
Received: from draper.com by RELAY.CS.NET id af09120; 14 Mar 89 10:11 EST
Date: Tue, 14 Mar 89 08:19 EST
From: "Steve Bacher (Batchman)" <SEB1525@draper.com>
Subject: Re: Issue PEEK-CHAR-READ-CHAR-ECHO
To: cl-cleanup@SAIL.STANFORD.EDU
X-VMS-To: CL-CLEANUP,SEB1525
> From: "Kim A. Barrett" <IIM%ECLA@eclc.usc.EDU>
> Subject: Issue PEEK-CHAR-READ-CHAR-ECHO
> To: kmp@scrc-stony-brook.ARPA
> Cc: cl-cleanup@sail.stanford.EDU, iim%ECLA@eclc.usc.EDU
> 1. Define two operations on streams, ECHO and UNECHO.
> 2. echo-streams, when reading a character, apply echo to the output stream and
> the character. unread on echo-streams calls unecho on the output stream
> and char, in addition to passing along the unread to the input stream.
> 3. Other meta-streams simply pass these operations along to their output side.
> 4. data-streams have two choices, depending on whether they have the
> capability to 'back out' output. If they can back it out, then echo is
> equivilent to write-char, and unecho backs it out. If they can't, then
> they record the echo in a slot, writing any already pending echo. unecho
> clears the pending echo slot. all normal output operations first write
> pending echo. a normal close also forces pending echoing.
> There is potentially more hair involved, intended to either support or
> complain about improper usage, like calling unread after peek, doing output
> between the read and the unread, &etc. Note that this depends on the single
> unread restriction in order to work right in all cases.
There SURE IS more hair involved. All you're doing is punting the basic
problem down to a lower level. Maybe the stream internally takes the actual
send-the-character-to-the-output-stream and implements it via SEND-OUT and
UN-SEND-OUT calls, where SEND-OUT buffers the character in case an UN-SEND-OUT
comes along...
In the
'foo(* a b)
example, when the ( is seen, either it gets echoed at that point or it
doesn't. This ECHO/UNECHO stuff doesn't change anything. And posing a
restriction on stream output between READ and UNREAD is unreasonable,
in my opinion.
∂14-Mar-89 0738 CL-Cleanup-mailer More re: PEEK-CHAR-READ-CHAR-ECHO
Received: from RELAY.CS.NET by SAIL.Stanford.EDU with TCP; 14 Mar 89 07:38:47 PST
Received: from relay2.cs.net by RELAY.CS.NET id ad25718; 14 Mar 89 10:16 EST
Received: from draper.com by RELAY.CS.NET id ag09120; 14 Mar 89 10:12 EST
Date: Tue, 14 Mar 89 08:22 EST
From: "Steve Bacher (Batchman)" <SEB1525@draper.com>
Subject: More re: PEEK-CHAR-READ-CHAR-ECHO
To: cl-cleanup@SAIL.STANFORD.EDU
X-VMS-To: CL-CLEANUP,SEB1525
Just for the record, I wouldn't wish to see any proposal adopted that didn't
support the notion of PEEK-CHAR being equivalent to READ-CHAR + UNREAD-CHAR.
Maybe the IIM implementation solves this problem - or thinks it does - but
I don't see quite how.
∂14-Mar-89 0756 CL-Cleanup-mailer Re: Issue: DESTRUCTURING-BIND (Version 2)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 14 Mar 89 07:56:43 PST
Received: from Semillon.ms by ArpaGateway.ms ; 14 MAR 89 07:48:32 PST
Date: 14 Mar 89 07:48 PST
From: masinter.pa@Xerox.COM
Subject: Re: Issue: DESTRUCTURING-BIND (Version 2)
In-reply-to: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>'s message
of Wed, 25 Jan 89 11:38 EST
To: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
cc: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <890314-074832-22564@Xerox>
Version 2 is the most recent I have. There's been some debate about &WHOLE,
&ENVIRONMENT, NIL and IGNORE in the destructuring list.
&ENVIRONMENT:
everybody says disallow
&WHOLE:
Moon said allow (the second time.)
NIL:
Moon says allow as a way of ignoring.
KMP says OK.
&BODY:
KMP makes case for disallowing, but says
allow.
There was some additional discussion that resulted in the related issue of
DEFMACRO-LAMBDA-LIST.
I'd be happy with a proposal that said NIL is ignored, &WHOLE and &BODY are
allowed, and that &ENVIRONMENT is disallowed.
KMP made a reference to "the next version" in his message of 30 Jan 89, so
maybe he'll produce one.
Larry
∂14-Mar-89 0835 CL-Cleanup-mailer Re: Issue: CONDITION-RESTARTS (Version 1)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 14 Mar 89 08:35:34 PST
Received: from Semillon.ms by ArpaGateway.ms ; 14 MAR 89 08:28:15 PST
Date: 14 Mar 89 08:27 PST
From: masinter.pa@Xerox.COM
Subject: Re: Issue: CONDITION-RESTARTS (Version 1)
In-reply-to: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>'s message
of Sat, 11 Mar 89 22:03 EST
To: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>,
CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <890314-082815-22614@Xerox>
I don't think there will be any strong objection if, after some
consideration, you want to remove a function from the condition system,
even though it is "incompatible"; the condition system has not been with us
long enough that "tweaks" are out of line.
Should the condition system symbols be in the LISP package or the
CONDITIONS package? The current draft of the standard doesn't distinguish
their package.
∂14-Mar-89 0923 CL-Cleanup-mailer More re: PEEK-CHAR-READ-CHAR-ECHO
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 14 Mar 89 09:23:21 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 556600; Tue 14-Mar-89 12:11:10 EST
Date: Tue, 14 Mar 89 12:11 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: More re: PEEK-CHAR-READ-CHAR-ECHO
To: "Steve Bacher (Batchman)" <SEB1525@draper.com>
cc: cl-cleanup@SAIL.STANFORD.EDU
In-Reply-To: The message of 14 Mar 89 08:22 EST from "Steve Bacher (Batchman)" <SEB1525@draper.com>
Message-ID: <19890314171109.2.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Tue, 14 Mar 89 08:22 EST
From: "Steve Bacher (Batchman)" <SEB1525@draper.com>
Just for the record, I wouldn't wish to see any proposal adopted that didn't
support the notion of PEEK-CHAR being equivalent to READ-CHAR + UNREAD-CHAR.
Such a proposal was already adopted in January by an 11 to 5 vote. To clarify
the double negatives, PEEK-CHAR-READ-CHAR-ECHO as adopted in January eliminates
the equivalence of PEEK-CHAR to READ-CHAR+UNREAD-CHAR, but only when peeking
from a stream created by MAKE-ECHO-STREAM.
We can reconsider anything, of course, if that's how we want to spend our time.
∂14-Mar-89 1104 CL-Cleanup-mailer Re: Issue IGNORE-VARIABLE, v1
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 14 Mar 89 11:02:36 PST
Received: from Semillon.ms by ArpaGateway.ms ; 14 MAR 89 09:41:14 PST
Date: 14 Mar 89 09:03 PST
From: masinter.pa@Xerox.COM
Subject: Re: Issue IGNORE-VARIABLE, v1
In-reply-to: Kim A. Barrett <IIM%ECLA@ECLC.USC.EDU>'s message of Sun, 19
Feb 89 15:42:05 PST
To: Kim A. Barrett <IIM%ECLA@ECLC.USC.EDU>
cc: cl-cleanup@SAIL.STANFORD.EDU
Message-ID: <890314-094114-1073@Xerox>
I didn't check the references when this was first proposed, but presumably
pp 55-56 and 59-65 of CLtL have some indication that duplicates are not
allowed. This issue was "withdrawn", i.e., we didn't propose it.
----- Begin Forwarded Messages -----
Date: Mon, 7 Mar 88 15:06 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: LAMBDA-LIST-DUPLICATES (Version 1)
To: CL-Cleanup@SAIL.Stanford.EDU
Issue: LAMBDA-LIST-DUPLICATES
References: 5.1.2 Variables (pp55-56)
5.2.2 Lambda-Expressions (pp59-65),
LET* (p111-112), PROG* (pp131-132)
Category: ADDITION
Edit history: 07-Mar-88, Version 1 by Pitman
Related Issues: DECLARATION-SCOPE
Status: For Internal Discussion
Problem Description:
CLtL forbids binding the same variable more than once in the same
binding form. This rule is claimed by some to be overly restrictive
because there are some well-defined situations in which it would be
useful to duplicate a variable name in the same binding list.
Proposal (LAMBDA-LIST-DUPLICATES:ALLOW-SEQUENTIAL-NON-ITERATIVE):
Allow variable names to be repeated in situations where bindings are
sequential and the binding construct is non-iterative (specifically,
in the &AUX part of a normal lambda list, in the bindings of LET*, and
in the bindings of PROG*).
Test Case:
((LAMBDA (B &AUX (B (+ B 1)) (B (+ B 1))) B) 0) => 2
(LET* ((B 0) (B (+ B 1))) B) => 1
(PROG* ((B 0) (B (+ B 1))) (RETURN B)) => 1
Rationale:
Because these bindings are inherently sequential and non-iterative, there
would no ambiguity about the intended scope bindings, and it is sometimes
useful to repeat the name of a binding when doing various kinds of
encapsulations or successive refinements to the same value.
The intent of duplicated bindings in "parallel binding" constructs like
LET or iterative constructs like DO* is less easy to predict, so it is
not proposed that the current rule be relaxed for such constructs.
Current Practice:
The Symbolics implementation currently checks for this case and
signals an error.
[Others?]
Cost to Implementors:
Converting would be relatively easy, but not completely trivial.
There is some interaction with declaration processing which becomes
involved, too (see issue DECLARATION-SCOPE).
Cost to Users:
None. This is an upward-compatible change.
Cost of Non-Adoption:
Some useful expressional style would be lost.
Benefits:
A useful expressional style would be made available.
Aesthetics:
The rule for variable duplication would be more syntactically complex
but pragmatically simpler.
Discussion:
A request for a discussion of this issue came from the Japanese
community.
Pitman drafted this formal proposal and supports
LAMBDA-LIST-DUPLICATES:ALLOW-SEQUENTIAL-NON-ITERATIVE.
----- Next Message -----
From: Jeff Dalton <jeff%aiva.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK>
Date: Tue, 8 Mar 88 20:28:54 gmt
To: CL-Cleanup@sail.stanford.edu
Subject: Issue: LAMBDA-LIST-DUPLICATES (Version 1)
Cc: KMP@scrc-stony-brook.arpa
Current practice:
Both PopLog Common Lisp and KCL allow variables to appear more
than once in a lambda-list. In the three suggested test cases,
they both have the later binding current in the body of the form
and so return the values 2, 1, and 1 respectively.
In addition, both allow variables in other cases, specifically:
KCL:
((lambda (a a) a) 1 2) => 2
PopLog:
((lambda (a a) a) 1 2) => 1
----- Next Message -----
Date: Fri, 11 Mar 88 13:43 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: LAMBDA-LIST-DUPLICATES (Version 1)
To: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
cc: CL-Cleanup@SAIL.STANFORD.EDU
In-Reply-To: <880307150614.2.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
I oppose LAMBDA-LIST-DUPLICATES:ALLOW-SEQUENTIAL-NON-ITERATIVE; I think
Common Lisp should continue to forbid binding the same variable more
than once in the same binding form. I have two reasons:
1. This is an unnecessary complication of the language rules. Allowing
duplicated variable names doesn't make it possible to write programs
that you couldn't write before, it just allows the programs to be
written in a more obscure way.
2. This would result in an unnecessary complication of the scoping rules
for DECLARE. Common Lisp would have to define what happens when a
DECLARE of a variable is attached to a form that binds more than one
variable with the declared name.
----- End Forwarded Messages -----
∂14-Mar-89 1253 CL-Cleanup-mailer re: PATHNAME-PRINT-READ, v1
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 14 Mar 89 12:53:02 PST
Received: from Semillon.ms by ArpaGateway.ms ; 14 MAR 89 12:33:37 PST
Date: 14 Mar 89 12:32 PST
From: masinter.pa@Xerox.COM
Subject: re: PATHNAME-PRINT-READ, v1
In-reply-to: Kim A. Barrett <IIM%ECLA@ECLC.USC.EDU>'s message of Thu, 9 Feb
89 11:25:54 PST
To: Kim A. Barrett <IIM%ECLA@ECLC.USC.EDU>
cc: cl-cleanup@SAIL.STANFORD.EDU
Message-ID: <890314-123337-1569@Xerox>
If this is going to be discussed at the X3j13 meeting, we should have
a new version with all of the various additions to current practice
and discussions appended.
pierson says:
KCL uses #"..."
EB says:
"For Current Practice:
Lucid CL also implements the proposed behavior.
For Cost to Users:
Users who define their own #P read macro may be unhappy.
I weakly support this change.
..."
Masinter says:
"For Current Practice, Envos Medley prints pathnames with the syntax #.(pathname "asdf").
I like #P"asdf" better, but #.(pathname string) is currently pretty portable.
"
Barrett says:
"For Current Practice, IIM Common Lisp prints pathnames with the syntax
#.(parse-namestring "asdf" "host"). The reason for using this convention is
that for some strings you need to know what parsing conventions to use in order
to get back an equivalent pathname. And yes, I agree it is ugly and verbose.
"
KMP and kab sent a long messages but I can't summarize easily.
Mly says "I still don't understand why this needs to be standardised upon..."
and "Even if others do feel an urgent need to allow such portablability, I
don't understand why #S(PATHNAME ...) syntax isn't acceptable."
∂14-Mar-89 1317 CL-Cleanup-mailer Re: PATHNAME-PRINT-READ, v1
Received: from multimax.encore.com ([129.91.1.14]) by SAIL.Stanford.EDU with TCP; 14 Mar 89 13:17:08 PST
Received: from mist.encore.COM by multimax.encore.com with SMTP (5.61/25-eef)
id AA18290; Tue, 14 Mar 89 16:16:11 -0500
Received: from localhost by mist. (4.0/SMI-4.0)
id AA05011; Tue, 14 Mar 89 16:13:03 EST
Message-Id: <8903142113.AA05011@mist.>
To: masinter.pa@Xerox.COM
Cc: cl-cleanup@SAIL.STANFORD.EDU
Subject: Re: PATHNAME-PRINT-READ, v1
In-Reply-To: Your message of 14 Mar 89 12:32:00 -0800.
<890314-123337-1569@Xerox>
Date: Tue, 14 Mar 89 16:13:01 EST
From: Dan L. Pierson <pierson@mist.encore.com>
Date: 14 Mar 89 12:32 PST
From: masinter.pa@Xerox.COM
If this is going to be discussed at the X3j13 meeting, we should have
a new version with all of the various additions to current practice
and discussions appended.
pierson says:
KCL uses #"..."
Absolutely true. However I don't approve of it for several reasons:
#P is more prevalent
Issue: PRETTY-PRINT-INTERFACE puts #"..." to a better use. This
is relevant for those of us who will use Water's pretty printer
whether or not the issue passes.
#"..." is just too good a "name" to be reserved for pathname syntax.
∂14-Mar-89 1344 CL-Cleanup-mailer Re: Issue: LOAD-TRUENAME (Version 1)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 14 Mar 89 13:43:51 PST
Received: from Semillon.ms by ArpaGateway.ms ; 14 MAR 89 13:19:26 PST
Date: Tue, 14 Mar 89 13:19 PST
From: Gregor.pa@Xerox.COM
Subject: Re: Issue: LOAD-TRUENAME (Version 1)
To: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
cc: CL-Cleanup@SAIL.Stanford.EDU
Fcc: BD:>Gregor>mail>outgoing-mail-5.text.newest
In-Reply-To: <890313174517.3.KMP@BOBOLINK.SCRC.Symbolics.COM>
Message-ID: <19890314211919.6.GREGOR@SPIFF.parc.xerox.com>
Line-fold: no
I favor this. I would even favor either of the other two ideas even at
this `late date'. The behavior of each of the proposals is simple, its
easy to see what it will and won't do, and it satisfies a real demand.
I should note that I have never wanted the incremented functionally
offered by the `stack' proposals, but I could still vote for them.
-------
∂14-Mar-89 1344 CL-Cleanup-mailer Re: Issue: CLOS-CONDITIONS (Version 4)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 14 Mar 89 13:43:59 PST
Received: from Semillon.ms by ArpaGateway.ms ; 14 MAR 89 13:23:23 PST
Date: Tue, 14 Mar 89 13:23 PST
From: Gregor.pa@Xerox.COM
Subject: Re: Issue: CLOS-CONDITIONS (Version 4)
To: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
cc: Mly@AI.AI.MIT.EDU, CL-Cleanup@SAIL.Stanford.EDU
Fcc: BD:>Gregor>mail>outgoing-mail-5.text.newest
In-Reply-To: <890313130600.7.KMP@BOBOLINK.SCRC.Symbolics.COM>
Message-ID: <19890314212317.7.GREGOR@SPIFF.parc.xerox.com>
Line-fold: no
Date: Mon, 13 Mar 89 13:06 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
I do not agree that it is a -necessary- thing to specify the Meta-Class
of conditions because all intended uses of conditions can be done
without this information.
I don't agree with this. If we don't specify the metaclass, then users
won't know what other classes they can mix in when defining condition
classes. It may seem weird, but I can imagine someone wanting to mix
in an arbitrary class into a condition class.
I think we should just say that the class CONDITION is an instance of
STANDARD-CLASS, and that by default DEFINE-CONDITION defines standard
classes. Sure it might be nice to do the read only class thing but I
don't think this is a good time to design a special purpose metaclass
for this.
-------
∂14-Mar-89 1344 CL-Cleanup-mailer Issue: LOAD-TRUENAME (Version 1)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 14 Mar 89 13:44:43 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 556807; 14 Mar 89 16:42:03 EST
Date: Tue, 14 Mar 89 16:42 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: LOAD-TRUENAME (Version 1)
To: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
cc: CL-Cleanup@SAIL.Stanford.EDU
In-Reply-To: <890313174517.3.KMP@BOBOLINK.SCRC.Symbolics.COM>
Message-ID: <19890314214204.5.MOON@EUPHRATES.SCRC.Symbolics.COM>
I favor LOAD-TRUENAME:NEW-PATHNAME-VARIABLES. I think this
proposal would be greatly improved by adding two more variables,
*LOAD-PATHNAME* and *COMPILE-FILE-PATHNAME*, whose values are
the pathname opened by LOAD or COMPILE-FILE, rather than the
truename. The need for these is more obvious if you think
about systems where the pathname cannot be easily reconstructed
from the truename. This includes file systems with symbolic
links and some pathname systems with logical pathnames.
∂14-Mar-89 1358 CL-Cleanup-mailer Issue: TIME-ZONE-NON-INTEGER
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 14 Mar 89 13:57:52 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 556843; Tue 14-Mar-89 16:55:04 EST
Date: Tue, 14 Mar 89 16:55 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: TIME-ZONE-NON-INTEGER
To: chapman%aitg.DEC@decwrl.dec.com
cc: cl-cleanup@sail.stanford.edu, skona%csilvax@hub.ucsb.edu
In-Reply-To: <8903131137.AA05944@decwrl.dec.com>
Message-ID: <19890314215504.9.MOON@EUPHRATES.SCRC.Symbolics.COM>
TIME-ZONE-NON-INTEGER:ALLOW is okay with me.
∂14-Mar-89 1505 CL-Cleanup-mailer Issue: ERROR-NOT-HANDLED (Version 1)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 14 Mar 89 15:04:58 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 556941; Tue 14-Mar-89 18:02:30 EST
Date: Tue, 14 Mar 89 18:02 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: ERROR-NOT-HANDLED (Version 1)
To: cl-cleanup@sail.stanford.edu
cc: X3J13@sail.stanford.edu
In-Reply-To: <890314-140350-1917@Xerox>
Message-ID: <19890314230224.2.MOON@EUPHRATES.SCRC.Symbolics.COM>
ERROR-NOT-HANDLED:PERMIT-TERMINATION is okay with me. I would
also support a proposal to replace "the condition system as currently
described insists that the interactive debugger be entered if a
condition is unhandled" with wording that allowed implementations
to do whatever they want, with perhaps an implementation note that
many implementations prefer an interactive debugger.
∂14-Mar-89 1612 CL-Cleanup-mailer TYPE-OF-UNDERCONSTRAINED, version 4
Received: from Think.COM by SAIL.Stanford.EDU with TCP; 14 Mar 89 16:11:32 PST
Received: from fafnir.think.com by Think.COM; Tue, 14 Mar 89 16:46:54 EST
Return-Path: <gls@Think.COM>
Received: from verdi.think.com by fafnir.think.com; Tue, 14 Mar 89 16:48:13 EST
Received: by verdi.think.com; Tue, 14 Mar 89 16:45:02 EST
Date: Tue, 14 Mar 89 16:45:02 EST
From: Guy Steele <gls@Think.COM>
Message-Id: <8903142145.AA05320@verdi.think.com>
To: cl-cleanup@sail.stanford.edu
Cc: gls@Think.COM
Subject: TYPE-OF-UNDERCONSTRAINED, version 4
This is a proposal to amend version 3, passed as amended (to include
RANDOM-STATE) in January 1989 in Kauai.
Version 4 amends version 3 to add SHORT-FLOAT, LONG-FLOAT, and RATIONAL
to the list of types in part (a) of the proposal.
Forum: Cleanup
Issue: TYPE-OF-UNDERCONSTRAINED
References: TYPE-OF (CLtL)
88-002R (Class-of)
88-005, p 43f, Condition system types
Related issues: SUBTYPEP-TOO-VAGUE
DATA-TYPE-HIERARCHY-UNDERSPECIFIED
FUNCTION-TYPE
ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS
COERCE-INCOMPLETE
Category: CLARIFICATION/CHANGE
Edit history: Version 1, 1-Dec-88, Masinter
Version 2, 9-Dec-88, Masinter
Version 3, 12-Dec-88, Masinter (fix "egregious bug")
Versino 4, 3-14-89 Steele
Problem description:
The specification of TYPE-OF in CLtL is so weak as to leave it
nearly useless, if any implementor actually took the specification
seriously.In particular, there are almost no constraints on the
value that TYPE-OF might return for any of the built in
types. The only constraint placed is that for objects created by the
constructor function of DEFSTRUCT, the result of TYPE-OF is the name of the
defstruct.
This means that implementations could return T for all other objects.
Proposal (TYPE-OF-UNDERCONSTRAINED:ADD-CONSTRAINTS):
Specify that the result of TYPE-OF satisfies the following:
(a) For any object for which (typep object built-in-type) is true when
built-in-type is one of
INTEGER, RATIO, FLOAT, SINGLE-FLOAT, DOUBLE-FLOAT, COMPLEX, NUMBER
SYMBOL,
STRING, VECTOR, ARRAY, RANDOM-STATE
CONS,
STREAM, PACKAGE, CHARACTER, FUNCTION, READTABLE, HASH-TABLE, PATHNAME,
CONDITION, RESTART,
RATIONAL, SHORT-FLOAT, LONG-FLOAT
the result of TYPE-OF will be a type specifier for which
(subtypep (type-of object) built-in-type) returns T T, i.e., either the
build-in-type or a subtype of it (a subtype that the
implementation's SUBTYPEP can recognize.)
(b) For all objects, (TYPEP object (TYPE-OF object)) will be true.
(this implies that it will not be NIL, since no
object is of type NIL.)
(c) will not be a MEMBER type specifier, or T.
For objects created by the "constructor" function of a structure
defined with DEFSTRUCT without a :TYPE option, TYPE-OF
will return the structure name.
For objects created by MAKE-INSTANCE, giving a named
class, TYPE-OF will return the class name of the class.
For objects which are instances of anonymous classes (i.e., where
(CLASS-NAME (CLASS-OF object)) is NIL), the result of TYPE-OF should be the
class object itself.
(The CLOS specification has already specified that class objects are
acceptable wherever type specifiers are, and in particular, as input to
SUBTYPEP and TYPEP.)
This proposal is intended to be consistent with 88-002R,
and not to conflict with any of the definitions in that document.
Examples:
It is legal for (TYPE-OF "abc") to return (SIMPLE-STRING 3), or just
STRING. It is legal for (TYPE-OF 112312) to return SI:MEDIUM-SIZE-FIXNUM,
as long as (SUBTYPEP 'SI:MEDIUM-SIZE-FIXNUM 'INTEGER).
Given:
(defvar *foo* (make-array 5 :element-type t))
(class-name (class-of *foo*)) => SIMPLE-VECTOR
It is legal for
(type-of *foo*) => (SIMPLE-VECTOR 5)
Rationale:
The original specification for "TYPE-OF" was written to allow
implementation freedom, but the wording is in fact more vague than was
intended.
Current practice:
Most Common Lisp implementations seem to implement the proposal, at least
for the types we've tried them on.
Cost to Implementors:
Even if there are implementations that do not currently implement the
proposal, the required changes for them are likely to be minimal.
Cost to Users:
Apparently none.
Cost of non-adoption:
TYPE-OF would remain potentially inconsistent.
Performance impact:
Likely none.
Benefits:
Bring the specification of TYPE-OF in like with its common
implementation, while requiring it to be generally useful.
Esthetics:
Little effect.
Discussion:
Originally, TYPE-OF was concieved as being useful for information display.
CLOS specified CLASS-OF far more precisely, in that it must return exactly
the class of an object. Unless TYPE-OF is removed from the language, it
seems reasonable to require it to be at least as precise as CLASS-OF.
The accepted CLOS specification does not define CLASS-OF
in terms of TYPE-OF, but an earlier draft did.
This proposal presumes the (passed) proposals
DATA-TYPES-HIERARCHY-UNDERSPECIFIED:DISJOINT, FUNCTION-TYPE, and
accomodates the Condition System (version 18) and CLOS.
If ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS does not pass,
and this proposal does pass, it may be that the only way an
implementation can satisfy (TYPEP array (TYPE-OF array))
would be to have (TYPE-OF array) return VECTOR or ARRAY
as appropriate, i.e., with no element type qualification.
It is possible to constrain TYPE-OF further, e.g., to eliminate
the possibility that it might return a non-portable
implementation-specific value. For example,
(TYPE-OF 112312) should not return SI:MEDIUM-SIZE-FIXNUM, but rather some
thing like (SIGNED-BYTE 17) [if that's what SI:MEDIUM-SIZE-FIXNUM means.]
We would like to make this as an implementation recommendation,
however, rather than as a constraint, at this point.
∂14-Mar-89 1613 CL-Cleanup-mailer SYMBOL-MACROLET-SEMANTICS, version 6
Received: from Think.COM by SAIL.Stanford.EDU with TCP; 14 Mar 89 16:12:48 PST
Received: from fafnir.think.com by Think.COM; Tue, 14 Mar 89 16:42:18 EST
Return-Path: <gls@Think.COM>
Received: from verdi.think.com by fafnir.think.com; Tue, 14 Mar 89 16:43:40 EST
Received: by verdi.think.com; Tue, 14 Mar 89 16:40:28 EST
Date: Tue, 14 Mar 89 16:40:28 EST
From: Guy Steele <gls@Think.COM>
Message-Id: <8903142140.AA05308@verdi.think.com>
To: cl-cleanup@sail.stanford.edu
Cc: gls@Think.COM
Subject: SYMBOL-MACROLET-SEMANTICS, version 6
This is a proposal to amend version 5, passed in January 1989 in Kauai.
Version 6 amends version 5 to require PSETQ to behave like PSETF,
to require MULTIPLE-VALUE-SETQ to accept symbol macros (but not
general SETF places), and to specify the interaction with the
*MACROEXPAND-HOOK* function.
Issue: SYMBOL-MACROLET-SEMANTICS
References: SYMBOL-MACROLET (88-002R page 2-81)
Related Issues: SYMBOL-MACROLET-DECLARE
Category: CHANGE
Edit history: 29-July-88, Version 1 by Piazza
21-September-88, Version 2 by Piazza
22-September-88, Version 3 by Piazza
22-September-88, Version 4 by Piazza
30-Nov-88, Version 5 by Masinter
14-Mar-89, Version 6 by Steele
Problem Description:
The SYMBOL-MACROLET construct, introduced with CLOS in X3J13 document
88-002R, profoundly alters the interpretation of symbols appearing as
forms in a Common Lisp program--what previously was necessarily a variable
might now be a symbol macro instead. Macros which appear in the body of a
SYMBOL-MACROLET form are currently unable to determine whether a symbol
form is a variable or a symbol macro, and, if the latter, what the
expansion of the symbol macro is. Consequently, complex macros (such as
SETF or PUSH) which depend on the form of their argument(s), are unable to
produce their desired results in some cases, as in the following example:
(let ((a (make-array 5))
(i 0))
(symbol-macrolet ((place (aref a (incf i))))
(push x place))
i) ==> 2
In addition, it would be both natural and nice to be able to write
(with-slots (rho theta) point
(declare (single-float rho theta))
...computation...)
as well as DECLARE within SYMBOL-MACROLET forms.
Proposal (SYMBOL-MACROLET-SEMANTICS:SPECIAL-FORM):
Change the definition of SYMBOL-MACROLET to specify that it is a special
form, which affects the evaluation environment for symbols. Enhance
MACROEXPAND and MACROEXPAND-1 so that they can expand a symbol macro.
Modify SETF et al to use the new MACROEXPAND and MACROEXPAND-1 to examine
even symbol subforms. Specify that the expansion of a symbol macro IS
subject to further macro expansion in the same lexical environment as the
symbol macro invocation, exactly analogous to normal macros. Clarify that
within the body of a SYMBOL-MACROLET, SETQ of a symbol defined as
a symbol macro will be treated as if it were a SETF.
Furthermore PSETQ of a symbol defined as a symbol macro will
behave as if it were a PSETF, and MULTIPLE-VALUE-SETQ will behave
as if SETQ were used on each variable to be set.
When MACROEXPAND or MACROEXPAND-1 sees a symbol macro, it calls
the value of *MACROEXPAND-HOOK* in the same manner as for an
ordinary macro. The three values given to the hook function
in this case will be an expansion function, a form (in this case
the symbol naming the symbol macro), and an environment. The
only guaranteed property of the expansion function is that when
it is applied to the form and the environment it will return the
correct expansion of the symbol macro. (In particular, nothing
it said in this specification whether the expansion is conceptually
stored in the expansion function, the environment, or both.)
Rationale:
The potential for interaction between macros is exactly why &environment
arguments were originally added to macros. Changing SYMBOL-MACROLET to be
a special form, which communicates through the &environment arguments to
macros with MACROEXPAND and MACROEXPAND-1, would allow PUSH and SETF
(among others) to work with SYMBOL-MACROLET in the same way they work with
MACROLET.
This change cannot (reasonably) support the currently specified semantics
that the expansion text is "outside" the scope of the symbol macro. For
indeed, when the symbol macro is expanded, (a copy of) the expansion is
then within the scope of the SYMBOL-MACROLET, and should then be subject
to further scrutiny. The issue of "infinite expansion" of symbol macros is
no more dangerous than that of normal macros.
Current Practice:
Portable Common Loops provides a code-walking implementation of
SYMBOL-MACROLET as specified in 88-002R. Symbolics Cloe has both a
code-walking version of a SYMBOL-MACROLET macro and compiler support for
a SYMBOL-MACROLET special form.
Cost to Implementors:
If SYMBOL-MACROLET is modified to be a special form, compilers and
interpreters will have to change, as well as MACROEXPAND, MACROEXPAND-1,
PUSH, INCF, DECF, and others.
Cost to Users:
If SYMBOL-MACROLET is converted to a special form, code-walking programs
will have to be modified to handle SYMBOL-MACROLET correctly. Those same
programs would have to be modified to handle the other special forms
specified in CLOS, anyway.
Cost of Non-Adoption:
SYMBOL-MACROLET will retain its confusing semantics, leading to bugs when
it interacts with complex macros and forms which produce side-effects.
Implementations which support ONCE-ONLY will break. For that matter, any
mechanism which examines code and assumes that "variables" have no side
effects will break.
Benefits:
SYMBOL-MACROLET-SEMANTICS:SPECIAL-FORM avoids the hairiest problems
surrounding interaction of macros (like SETF) and side effects, and makes
SYMBOL-MACROLET consistent with MACROLET.
Aesthetics:
If SYMBOL-MACROLET is made to be a special form, aesthetics are improved
by making symbol macros consistent with normal macros.
Discussion:
A case could be made for adding a new function, SYMBOL-MACRO-FUNCTION, as
a dual of MACRO-FUNCTION. However, symbol macros are simpler than normal
macros: a symbol macro is associated with a single expansion form, rather
than an arbitrary function which computes the expansion. For this reason,
the augmented MACROEXPAND-1 proposed here can also fill the role of
SYMBOL-MACRO-FUNCTION: the second value of (macroexpand-1 sym env) will be
T if and only if sym is a symbol macro, while the first value gives the
expansion of sym, if it has one.
Rather than extending the existing MACROEXPAND and MACROEXPAND-1
functions, new functions could be introduced to expand symbol macros.
However, there seems to be no particular reason to do this.
∂14-Mar-89 1731 CL-Cleanup-mailer Re: Issue: READ-CASE-SENSITIVITY (Version 1)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 14 Mar 89 17:30:51 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 14 MAR 89 14:18:15 PST
Date: 14 Mar 89 14:17 PST
From: masinter.pa@Xerox.COM
Subject: Re: Issue: READ-CASE-SENSITIVITY (Version 1)
In-reply-to: David N Gray <Gray@DSG.csc.ti.com>'s message of Thu, 9 Mar 89
18:01:27 CST
To: David N Gray <Gray@DSG.csc.ti.com>, Jeff Dalton
<jeff@aiai.edinburgh.ac.uk>
cc: cl-cleanup@sail.stanford.edu
Message-ID: <890314-141815-1956@Xerox>
I have 15 replies to version 1, but no version 2.
Personally, I think adding a character translation table is overkill if all
that's wanted is case sensitive or no, and the performance cost unwieldy.
"Gilding the lilly."
Why not just (READTABLE-CASE <readtable>) that accepts/returns :UPCASE (the
default) or :DOWNCASE.
Note that the setting of the READTABLE-CASE in *READTABLE* should affect
printing: if (READTABLE-CASE *READTABLE*) is :DOWNCASE, then *PRINT-CASE*
is ignored; symbols should be printed with the same case as their internal
name.
This is effectively what Medley does; it was necessary to support
readtables with a case sensitive "bit" so that the same environment could
simultaneously support Interlisp (which is case sensitive) and Common Lisp.
If this is going to go anywhere, we'll need a version 2. If you want to
proceed with just the READTABLE-CHARACTER-TRANSLATION, I won't squawk too
loudly (but I think I would vote against all of the proposals, even the one
I outline above, on the grounds that they are 'unnecessary' complications.)
∂14-Mar-89 1731 CL-Cleanup-mailer RE: Cleanup Issue Status
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 14 Mar 89 17:31:21 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 14 MAR 89 15:36:44 PST
Date: 14 Mar 89 15:35 PST
From: masinter.pa@Xerox.COM
Subject: RE: Cleanup Issue Status
In-reply-to: your message of Sun, 19 Feb 89 23:14:37 PST
To: chapman%aitg.DEC@decwrl.dec.com
cc: cl-cleanup@sail.stanford.edu
Message-ID: <890314-153644-2132@Xerox>
I have finally gotten around to reconciling your errata list from my status
list. Our differences are now:
> >+ DECLARE-ARRAY-TYPE-ELEMENT-REFERENCES
> >Version 3, 13-Jan-89
> >Status: passed, Jan 89 X3J13
> I believe this one was amended.
-- I have no amendments marked. Do you know what the amendment was?
> >+ DEFSTRUCT-REDEFINITION
> >Synopsis: what happens if you redefine a DEFSTRUCT?
> >Version 3, 6-Feb-89
> >Status: Passed (as amended) Jan 89 X3J13
> I don't have this one marked as amended.
-- Version 3 is the "amended" version, and was distributed after X3J13.
> >- DELETE-FILE-NONEXISTENT
> >Version 1, 5-Oct-88
> >Comments: should just signal different errors?
> >Status: withdrawn
> I marked this as tabled.
-- I know no-one who intends to raise it. Maybe KMP's error signalling
proposal? I'll check.
> >- ELIMINATE-FORCED-CONSING
> >Synopsis: Add :RECYCLE or :MODIFY to some sequence fns,
> >Version 3, 31-Aug-88
> >Status: withdrawn
> I marked this as tabled.
-- No, I think we all thought this was a bad idea after all.
> >- FORMAT-ROUNDING
> >Synopsis: specify that ~F rounds up
> >Version 1, 5-Oct-88
> >Status: withdrawn
> I marked this as tabled.
-- This was your issue originally. JonL said: "However, both Moon and I
seemed to prefer not trying to specify something in the standard for the
case this issue is addressing." and there was no dissent. Do you want to
re-raise it?
> >+ FUNCTION-COMPOSITION
> >Synopsis: Add new functions
> >Version 5, 10-Feb-89
> >Status: Passed (as amended) Jan 89 X3J13
> I know this is picky, but I thought it was decided to fail this one
> completely and amend TEST-NOT-IF-NOT (I believe that was the related
> issue).
-- you may be right. I wish we had minutes. I guess I'll stick by my
summary unless I hear otherwise.
> >+ PEEK-CHAR-READ-CHAR-ECHO
> >Version 3, 8-Oct-88, Released 8 Oct 88
> >Synopsis: PEEK-CHAR, READ-CHAR on streams made by MAKE-ECHO-STREAM
> >Status: Passed, Jan 89 X3J13
> I have this marked as amended.
-- I have no amendments made at the meeting. Do you?
> >- TRACE-ERROR
> >Synopsis: TRACE should signal errors if it doesn't understand
> >Version 1, 20-Jun-88
> >Comments: is this a cleanup?
> >Status: withdrawn
> I marked this as tabled.
-- I don't have anyone willing to bring it up.
∂14-Mar-89 1732 CL-Cleanup-mailer revised: Cleanup Issue Status
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 14 Mar 89 17:31:47 PST
Received: from Semillon.ms by ArpaGateway.ms ; 14 MAR 89 16:17:29 PST
Date: 14 Mar 89 16:16 PST
From: masinter.pa@Xerox.COM
Subject: revised: Cleanup Issue Status
In-reply-to: your message of Sun, 19 Feb 89 23:14:37 PST
To: chapman%aitg.DEC@decwrl.dec.com
cc: cl-cleanup@sail.stanford.edu
Message-ID: <890314-161729-2231@Xerox>
Ooops... I missed your later note about "amendments" being just "notes".
Our differences are now only over whether things were "tabled" or
"withdrawn" and whether FUNCTION-COMPOSITION was amended or whether it was
rejected with TEST-NOT-IF-NOT amended to include what was left of it:
> >- DELETE-FILE-NONEXISTENT
> >Version 1, 5-Oct-88
> >Comments: should just signal different errors?
> >Status: withdrawn
> I marked this as tabled.
-- I know no-one who intends to raise it. Maybe KMP's error signalling
proposal? I'll check.
> >- ELIMINATE-FORCED-CONSING
> >Synopsis: Add :RECYCLE or :MODIFY to some sequence fns,
> >Version 3, 31-Aug-88
> >Status: withdrawn
> I marked this as tabled.
-- No, I think we all thought this was a bad idea after all.
> >- FORMAT-ROUNDING
> >Synopsis: specify that ~F rounds up
> >Version 1, 5-Oct-88
> >Status: withdrawn
> I marked this as tabled.
-- This was your issue originally. JonL said: "However, both Moon and I
seemed to prefer not trying to specify something in the standard for the
case this issue is addressing." and there was no dissent. Do you want to
re-raise it?
> >+ FUNCTION-COMPOSITION
> >Synopsis: Add new functions
> >Version 5, 10-Feb-89
> >Status: Passed (as amended) Jan 89 X3J13
> I know this is picky, but I thought it was decided to fail this one
> completely and amend TEST-NOT-IF-NOT (I believe that was the related
> issue).
-- you may be right. I wish we had minutes. I guess I'll stick by my
summary unless I hear otherwise.
> >- TRACE-ERROR
> >Synopsis: TRACE should signal errors if it doesn't understand
> >Version 1, 20-Jun-88
> >Comments: is this a cleanup?
> >Status: withdrawn
> I marked this as tabled.
-- I don't have anyone willing to bring it up.
∂14-Mar-89 1732 CL-Cleanup-mailer Issue: PRETTY-PRINT-INTERFACE (Version 1)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 14 Mar 89 17:32:09 PST
Received: from Semillon.ms by ArpaGateway.ms ; 14 MAR 89 17:05:00 PST
Date: 14 Mar 89 17:04 PST
From: masinter.pa@Xerox.COM
Subject: Issue: PRETTY-PRINT-INTERFACE (Version 1)
In-reply-to: Guy Steele <gls@Think.COM>'s message of Fri, 24 Feb 89
17:40:25 EST
To: Guy Steele <gls@Think.COM>
cc: cl-cleanup@sail.stanford.edu
Message-ID: <890314-170500-2365@Xerox>
Dan Pierson had a few specific comments.
Kim Barrett says
"... The stuff about ~W providing circularity detection, and ~<...~:>
providing
depth abbreviation and circularity detection is wrong. This functionality
should always be provided, and not require the use of special format
directives
to get it. See the recently passed issue PRINT-CIRCLE-STRUCTURE...."
Can we get a new version that addresses those comments?
I think if we email things out by Thursday we might have a chance of
avoiding the "two-weekers".
Thanks,
Larry
∂14-Mar-89 1732 CL-Compiler-mailer Re: Potential issue: MACRO-SPECIAL-FORMS
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 14 Mar 89 17:32:00 PST
Received: from Semillon.ms by ArpaGateway.ms ; 14 MAR 89 16:49:34 PST
Date: 14 Mar 89 16:48 PST
From: masinter.pa@Xerox.COM
Subject: Re: Potential issue: MACRO-SPECIAL-FORMS
In-reply-to: Gregor.pa's message of Thu, 9 Mar 89 19:14 PST
To: Gregor.pa@Xerox.COM, David A. Moon
<Moon@STONY-BROOK.SCRC.Symbolics.COM>, Jeff Dalton
<jeff%aiai.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK>, Kent M Pitman
<KMP@STONY-BROOK.SCRC.Symbolics.COM>, cl-compiler@sail.stanford.edu,
cl-cleanup@sail.stanford.edu
Message-ID: <890314-164934-2319@Xerox>
a) if anything is going to happen on this at the next meeting, we need a
proposal writeup. This week.
b) I like the proposal (in Jeff's oiginal "potential issue"). I agree that
we might want something stronger -- like extending the list of special
forms to include the ones that a code walker *really* has to know about,
but I don't know if we can reach closure.
c) I'd rather do nothing than do something wrong.
∂14-Mar-89 1743 CL-Cleanup-mailer Issue: FORMAT-PLURALS (not yet submitted)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 14 Mar 89 17:43:47 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 14 MAR 89 17:31:41 PST
Date: 14 Mar 89 17:31 PST
From: masinter.pa@Xerox.COM
Subject: Issue: FORMAT-PLURALS (not yet submitted)
In-reply-to: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>'s message
of Mon, 6 Mar 89 23:50 EST
To: Dave.Touretzky@cs.cmu.edu
cc: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <890314-173141-2452@Xerox>
Is there a chance you could produce a revised version, in "standard"
writeup format in the next day or two? There have been significant
comments since your original message. There seems to be willingness
in cleanup committee to pursue this.
I don't know how much patience you have for our cumbersome procedures,
especially given your 'hit ratio'.
!
Format for proposals to the cleanup committee (Version 14)
October 5, 1988
Replace the text below in >> double inverted angle-brackets <<. Be
brief; leave testimonials and personal opinions to the discussion at the
end. Be complete; do not expect someone else to fix or redesign parts.
Spell out names (e.g., Masinter rather than LMM) and upper-case all Lisp
symbols (DEFUN rather than Defun). I like it better if you write in the
third person rather than first.
Remember that this is a proposal to a change to the standard
for Common Lisp, not recommendations to the editor, not
a set of recommendations to Common Lisp implementors.
Forum: Cleanup
Issue: >>A short descriptive label, which starts with a name
which occurs in the index of CLtL, and be a suitable
symbol in the Common Lisp style, e.g., CDR-TERMINATION.
When in doubt, let the cleanup committee assign the name.
The name should match the problem description, not the
proposal.<<
References: >>The pages of CLtL which describe the feature being
discussed, and other references.<<
Related issues: >> names of other cleanup issues about the same topic.<<
Category: >>One or more of:
CLARIFICATION -- proposal to resolve an ambiguity or case
of under-specified situation in CLtL, where this
ambiguity interferes with portability of code.
CHANGE -- proposal for an incompatible change.
ADDITION -- proposal for a compatible extension<<
Edit history: >>Author and date of submission (version 1), and author
and date of subsequent versions.<<
Problem description:
>>Describe the problem being addressed -- why is the current situation
unclear or unsatisfactory? Avoid describing the proposal here or arguing
for its adoption. <<
Proposal (>>issue-label:proposal-label<<): >> Describe as precisely as
possible what you are proposing. This can take the form of
text that could be dropped into the new specification document.
Proposals should be for changes to Common Lisp, rather than changes to
CLtL. If necessary, propose a set of labelled alternatives here, rather
than a single proposal. Each proposal must be a complete design; do not
leave out details. Avoid arguing for the proposal here, just describe
it.<<
Examples:
>> Examples are samples of Common Lisp code that illustrates the issue.
along with explanatory text. Please explain what the examples should
do, do in current implementations, and any special tricks.<<
Test Cases:
>> Test Cases are simple stand-alone expressions which are valid and
do not signal an error if the proposal is adhered to. (Use ASSERT
if needed.) Omit if you have none.
<<
Rationale:
>> A one or two sentence summary of the arguments that follow. <<
Current practice:
>>Do some/many/no Common Lisp implementations already work this way?
Survey independent Common Lisp implementations - preferably three or
more. What do they do on the test cases or examples? What do current
user programs do? Are there textbooks which describe this feature? <<
Cost to Implementors:
>>What is the cost to implementors of adopting the proposal? How much
implementation effort is required? Is public-domain code available? For
pervasive changes, can the conversion be automated?<<
Cost to Users:
>>For incompatible changes, what is the cost to users of converting
existing user code? To what extent can the process be automated? How?<<
Cost of non-adoption:
>>How serious is it if nothing is done? <<
Performance impact:
>> what does the proposal do to better or worsen the size or speed
of user programs and implementations? <<
Benefits:
>>What is better if the proposal is adopted? How serious is the problem
if just left as it is? <<
Esthetics:
>>How does this proposal affect the simplicity of the language, ease of
learning, etc. You can spell it aesthetics if you like. <<
Discussion:
>> Additional arguments, discussions, endorsements, testimonials, etc.
should go here. Testimonials are the least effective; the discussion should
be useful to someone not already with the issue or those discussing it.
Avoid a blow-by-blow account of debates or recounting of history. <<
∂14-Mar-89 1756 CL-Cleanup-mailer Re: Issue: COPY-SYMBOL-PRINT-NAME (Version 1)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 14 Mar 89 17:55:56 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 14 MAR 89 17:46:04 PST
Date: 14 Mar 89 17:45 PST
From: masinter.pa@Xerox.COM
Subject: Re: Issue: COPY-SYMBOL-PRINT-NAME (Version 1)
In-reply-to: chapman%aitg.DEC@decwrl.dec.com's message of 8 Mar 89 08:22
To: chapman%aitg.DEC@decwrl.dec.com
cc: cl-cleanup@sail.stanford.edu, skona%csilvax@hub.ucsb.edu
Message-ID: <890314-174604-2496@Xerox>
Kathy:
Can you update this to say STRING= and summarize the subsequent discussion?
Thanks
Larry
∂14-Mar-89 1812 CL-Cleanup-mailer Re: Issue: READ-CASE-SENSITIVITY (Version 1)
Received: from PORSCHE.SCRC.Symbolics.COM ([128.81.41.69]) by SAIL.Stanford.EDU with TCP; 14 Mar 89 18:11:58 PST
Received: from BOBOLINK.SCRC.Symbolics.COM by PORSCHE.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 6566; Tue 14-Mar-89 20:43:54 EST
Date: Tue, 14 Mar 89 20:43 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: Issue: READ-CASE-SENSITIVITY (Version 1)
To: Masinter.PA@Xerox.COM
cc: CL-Cleanup@SAIL.Stanford.EDU
In-Reply-To: <890314-141815-1956@Xerox>
Message-ID: <890314204336.9.KMP@BOBOLINK.SCRC.Symbolics.COM>
Date: 14 Mar 89 14:17 PST
From: masinter.pa@Xerox.COM
Why not just (READTABLE-CASE <readtable>) that accepts/returns :UPCASE (the
default) or :DOWNCASE.
This would be fine, but I would prefer :PRESERVE rather than :DOWNCASE for the
alternate value. One might legitimately want :DOWNCASE as well (although it
would be near useless for CL, it might be useful for other things) so I wouldn't
want to lock down that name.
All in all, though, I like somebody's (Gray's?) suggestion of a function rather
than a table. The default being #'CHAR-UPCASE, and #'IDENTITY being another
obvious choice.
The reason I like the function rather than the keyword is that you don't have
to initially provide the alternate functionality -- user's can add it. In the
case of the keyword, it has to be given by the system so you're at the mercy
of the implementors as to which options you get. I think this feature is worth
the added complexity.
∂15-Mar-89 0542 CL-Cleanup-mailer Issue: COPY-SYMBOL-PRINT-NAME
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 15 Mar 89 05:41:51 PST
Received: by decwrl.dec.com (5.54.5/4.7.34)
id AA29246; Wed, 15 Mar 89 05:39:23 PST
Message-Id: <8903151339.AA29246@decwrl.dec.com>
Received: by decwrl.dec.com (5.54.5/4.7.34)
for cl-cleanup@sail.stanford.edu; id AA29246; Wed, 15 Mar 89 05:39:23 PST
From: chapman%aitg.DEC@decwrl.dec.com
Date: 15 Mar 89 08:29
To: cl-cleanup@sail.stanford.edu, skona%csilvax@hub.ucsb.edu
Subject: Issue: COPY-SYMBOL-PRINT-NAME
!
From: DECWRL::AITG::CHAPMAN "8-Mar-89 0822 GMT" 8-MAR-1989 08:32:30.91
To: cl-cleanup@sail.stanford.edu, skona%csilvax@hub.ucsb.edu
CC:
Subj: Issue: COPY-SYMBOL-PRINT-NAME
Issue: COPY-SYMBOL-PRINT-NAME
References: COPY-SYMBOL (p. 169)
Category: CLARIFICATION
Edit history: 1-MAR-89, Version 1 by Chapman
15-MAR-89, Version 2 by Chapman
Problem Description:
The description of COPY-SYMBOL states that it "returns a new uninterned
symbol with the same print name as sym (its first argument)". The words
"the same as" are not defined in CLtL. Do they mean EQ, EQUAL, ...?
Proposal (COPY-SYMBOL-PRINT-NAME:EQUAL)
The description of COPY-SYMBOL should read as follows:
"COPY-SYMBOL returns an uninterned
symbol whose print name is STRING= to
the print name of the symbol that is the first argument to COPY-SYMBOL."
Suggested implementation note:
The string should not be copied unnecessarily. In this case, the uninterned
symbol's print name would be EQ to the print name of the argument symbol.
Rationale:
This clarification resolves any possibility of ambiguity.
Current Practice:
Medley did this: the symbol names didn't really have a string header and
some symbol names (the "initial symbols" ) had a different place for
storing the actual characters than symbols created later. Unfortunately,
that means that SYMBOL-NAME has to CONS.
It wasn't so much a problem for Interlisp since most of the "string"
functions in Interlisp will take symbols, but in Common Lisp, it is a
performance hit. Poor design, but there's no reason to require SYMBOL-NAME
to return EQ strings.
In this case, the strings aren't EQ even though the string characters are
shared. (Think of it as strings displaced to a shared area.)
Adoption Cost:
?
Benefits:
Less ambiguity in the specification, and potentially more portable code.
Conversion Cost:
?
Aesthetics:
None.
Discussion:
∂15-Mar-89 0549 CL-Cleanup-mailer Issue: EQUAL-STRUCTURE (Version 7)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 15 Mar 89 05:49:48 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 15 MAR 89 05:43:34 PST
Date: 15 Mar 89 05:42 PST
From: masinter.pa@Xerox.COM
Subject: Issue: EQUAL-STRUCTURE (Version 7)
To: cl-cleanup@Sail.Stanford.Edu
cc: masinter.pa@Xerox.COM
line-fold: No
Message-ID: <890315-054335-3530@Xerox>
This is what I believe was voted in at the last meeting.
I'm not sure why we started discussing it again, but
I didn't see anything in the discussion that looked like
a proposal to revisit this issue.
!
Status: Passed as amended, Jan 89 X3J13
Issue: EQUAL-STRUCTURE
References: EQUAL (p80), EQUALP (p81)
Category: CLARIFICATION/CHANGE
Edit history: 18-Mar-88, Version 1 by Pitman
08-Jun-88, Version 2 by Masinter (add Benson's proposal)
23-Sep-88, Version 3 by Masinter (remove all but STATUS-QUO)
01-Oct-88, Version 4 by Masinter (fix description)
01-Oct-88, Version 5 by Pitman (correct wording, add discussion)
11-Jan-89, Version 6 by Pitman (attempt EQUALP correction)
15-Mar-89, Version 7 by Masinter (amended as per vote at Jan 89 X3J13)
Problem Description:
The behavior of EQUAL and EQUALP on structures is a subject of controversy.
At issue are whether these functions should descend the slots of structures
or use simply the structure's primitive identity (i.e., EQ) to test for
equivalence.
Proposal (EQUAL-STRUCTURE:MAYBE-STATUS-QUO):
Clarify that EQUAL and EQUALP do not descend any structures or data types
other than the ones explicitly specified in CLtL.
Type EQUAL Behavior EQUALP Behavior
Number uses EQL uses =
Character uses EQL uses CHAR-EQUAL
Cons descends descends
Bit-Vector descends descends
String descends descends
Pathname magic per CLtL same as EQUAL
Structure uses EQ uses EQ
other Array uses EQ descends
Hash-Table uses EQ (see below)
Instance (Standard-Object) uses EQ uses EQ
Other uses EQ uses EQ
Note that the order of this table is in some cases important, with upper
entries taking priority over lower ones.
EQUALP descends hash tables by first comparing the count of entries
and the :TEST function; if those are the same, it compares the
keys of the tables using the :TEST function and then the values
of the matching keys using EQUALP recursively.
Rationale:
There seem to be as many different equality primitives as there
are applications for them. None of the possible ways of changing
EQUAL or EQUALP are flawless. Given the inability to "fix" them,
it is better to leave them alone.
Current Practice:
We are unaware of any extensions to CLtL's set of operations,
although frequently users request them.
Cost to Implementors:
Since this seems to be compatible with the status quo, none.
Cost to Users:
Same
Cost of Non-Adoption:
Ongoing controversy about whether EQUAL and EQUALP "do the right thing".
Benefits:
A feeling that EQUAL and EQUALP exist and/or do what they do because serious
consideration was given and we consciously decided on a particular resolution
to the numerous questions that have come up about them.
Aesthetics:
There seems to be wide debate about what the proper aesthetics for
how equality should work in Common Lisp. While the status quo is not
aesthetically more pleasing than the various alternatives, aesthetic
considerations vary widely. Different people model structures
differently. Sometimes the same person models structures differently in
different situations. The question of which should be descended and which
should not is a very personal one, and the aesthetic attractiveness of any
of these options will vary from person to person or application to
application.
Discussion:
An earlier version of this issue with various alternatives was distributed
at the June 1988 X3J13 meeting. Since
this is a frequently raised issue, we thought we should submit it
as a clarification although there is no change to CLtL.
Options for which we considered proposals were:
- removing EQUAL and EQUALP from the standard.
- changing EQUALP to descend structures.
- changing EQUALP to be case sensitive.
- adding a :TEST keyword to EQUAL.
- making EQUAL a generic function
All of these had some serious problems.
The cleanup committee supports option STATUS-QUO.
It would be useful if descriptions of EQUAL and EQUALP contained some sort
of additional commentary alluding to the complex issues discussed here.
The following is offered to the Editorial staff as a starting point:
Object equality is not a concept for which there is a uniquely
determined correct algorithm. The appropriateness of an equality
predicate can be judged only in the context of the needs of some
particular program. Although these functions take any type of
argument and their names sound very generic, EQUAL and EQUALP are
not appropriate for every application. Any decision to use or not
use them should be determined by what they are documented to do
rather than any abstract characterization of their function. If
neither EQUAL nor EQUALP is found to be appropriate in a particular
situation, programmers are encouraged to create another operator
that is appropriate rather than blame EQUAL or EQUALP for ``doing
the wrong thing.''
!
Additional Comments to Version 6:
Version 6 attempts to fix some of the problems noted in Version 5.
There are still some open questions. Only the "Proposal"
part has been changed since Version 5; some of the costs,
benefits & other discussion is now incorrect.
Kent says:
Please read this very carefully before voting in favor of it.
There were a lot of Yes votes for the last version, which I think
had some serious bugs in it. This would be a very bad issue for
us to screw up.
Things that might need special attention:
- Moon contends that standard practice in Symbolics Lisp is
for instances to be compared using EQ under EQUALP, not by
descending. There may be performance issues involved here.
Some agreement needs to be reached.
- Neither the previous version of the proposal nor CLtL was
clear on what happens to pathnames under EQUALP. This showed
up when I converted the presentation below. That issue should
be addressed as well.
Hopefully if this version of the proposal isn't something you want to
vote yes for, at least it's in a suitable form for easy line-item
changes interactively in the meeting.
----- End Forwarded Messages -----
∂15-Mar-89 0641 CL-Cleanup-mailer Re: Issue: OPTIMIZE-SAFETY (Version 1)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 15 Mar 89 06:41:30 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 15 MAR 89 06:37:00 PST
Date: 15 Mar 89 06:36 PST
From: masinter.pa@Xerox.COM
Subject: Re: Issue: OPTIMIZE-SAFETY (Version 1)
In-reply-to: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>'s message
of Mon, 6 Mar 89 17:42 EST
To: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
cc: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <890315-063700-3610@Xerox>
My reading is that this is currently being pursued as an editorial issue
and that it will not appear on the "cleanup" list.
Y'all let me know if you disagree.
∂15-Mar-89 0720 CL-Cleanup-mailer Re: Issue ERROR-CHECKING-IN-NUMBERS-CHAPTER
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 15 Mar 89 07:19:00 PST
Received: from Semillon.ms by ArpaGateway.ms ; 15 MAR 89 07:03:16 PST
Date: 15 Mar 89 07:02 PST
From: masinter.pa@Xerox.COM
Subject: Re: Issue ERROR-CHECKING-IN-NUMBERS-CHAPTER
In-reply-to: Kim A. Barrett <IIM%ECLA@ECLC.USC.EDU>'s message of Sun, 12
Mar 89 16:01:13 PST
To: Kim A. Barrett <IIM%ECLA@ECLC.USC.EDU>
cc: kmp@symbolics.com, cl-cleanup@SAIL.STANFORD.EDU
Message-ID: <890315-070316-3648@Xerox>
I think NaNs should cause ARITHMETIC-ERROR, since "what's one man's NaN is
another man's number."
To put it another way, TYPE-ERROR is generally a sign of a program error
and the cases in which it is signalled should usually not vary from
implementation to implementation; however, which cases signal
ARITHMETIC-ERROR can vary depending on the implementation's floating number
range.
Should we define specific conditions to correspond to the IEEE conditions
as subtypes of ARITHMETIC-ERROR?
I think that it is important to bring this issue to the X3J13 meeting, even
if it isn't quite ready for vote.
If there's a new draft soon, we can have it available for discussion there,
and maybe get an "endorse in principle".
∂15-Mar-89 0720 CL-Cleanup-mailer
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 15 Mar 89 07:20:26 PST
Received: from Semillon.ms by ArpaGateway.ms ; 15 MAR 89 07:15:06 PST
Date: 15 Mar 89 07:14 PST
From: masinter.pa@Xerox.COM
To: alarson@src.honeywell.com (Aaron Larson)
cc: cl-cleanup@sail.stanford.edu
Message-ID: <890315-071506-3662@Xerox>
Unfortunately, there is a "nest" of cleanup items on pathnames
that have been postponed. Here's PATHNAME-SUBDIRECTORY-LIST.
----- Begin Forwarded Messages -----
Date: Wed, 28 Dec 88 14:32 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: PATHNAME-SUBDIRECTORY-LIST (Version 3)
To: CL-Cleanup@SAIL.STANFORD.EDU
cc: KMP@STONY-BROOK.SCRC.Symbolics.COM
Ok, I've been through and I think successfully merged all the pending
discussion, most of which seemed to center around issues of :UP.
-----
Issue: PATHNAME-SUBDIRECTORY-LIST
References: Pathnames (pp410-413), MAKE-PATHNAME (p416),
PATHNAME-DIRECTORY (p417)
Category: CHANGE
Edit history: 18-Jun-87, Version 1 by Ghenis.pasa@Xerox.COM
05-Jul-88, Version 2 by Pitman (major revision)
28-Dec-88, Version 3 by Pitman (merge discussion)
Status: For Internal Discussion
Related-Issues: PATHNAME-COMPONENT-CASE
Problem Description:
It is impossible to write portable code that can produce a pathname
in a subdirectory of a hierarchical file system. This defeats much of
the purpose of having an abstraction like pathname.
According to CLtL, only a string is a portable filler of the directory
slot, but in order to denote a subdirectory, the use of separators (such
as dots, slashes, or backslashes) would be necessary. The very fact that
such syntax varies from host to host means that although the
representation might be "portable", the code using that representation
is not portable.
This problem is even worse for programs running on machines on a network
that can retrieve files from multiple hosts, each using a different OS
and thus a different subdirectory delimiter.
Related problems:
- In some implementations "FOO.BAR" might denote the "BAR" subdirectory
of "FOO" while in other implementations because "." is not the
separator. To be safe, portable programs must avoid all potential
separators.
- Even in implementations where "." is the separator, "FOO.BAR" may be
recognized by some to mean the "BAR" subdirectory of "FOO" and by others
to mean `a seven letter directory with "." being a superquoted part of
its name'.
- In fact, CLtL does not even say for toplevel directories whether the
directory delimiters are a part. eg, is "foo" or "/foo" the directory
filler for a unix pathname "/foo/bar.lisp". Similarly, is "[FOO]" or
"FOO" the directory filler for a VMS pathname "[FOO]ME.LSP"?
Proposal (PATHNAME-SUBDIRECTORY-LIST:NEW-REPRESENTATION)
Allow a list to be a filler of a pathname. The car of the list may be either
of the symbols :ABSOLUTE or :RELATIVE.
If the car of the list is :RELATIVE, the rest of the list is the
implementation-dependent result of PARSE-NAMESTRING for file systems which
have relative pathnames. Unless some other proposal is submitted to clarify
the behavior of relative pathnames in merging, etc. that behavior is left
undefined.
If the car of the list is :ABSOLUTE, the rest of the list is a list of
strings each naming a single level of directory structure. The strings
should contain only the directory names themselves -- no separator
characters.
The spec (:ABSOLUTE) represents the root directory.
Clarify that if a string is used as a filler of a directory field in a
pathname, it should be the unadorned name of a toplevel directory.
Specifying a string, str, is equivalent to specifying the list
(:ABSOLUTE str).
In place of a string, at any point in the list, keyword symbols may occur
to deal with special file notations. The following symbols have standard
meanings; they may not be meaningful for all operating systems, and are
intended for use only on those operating systems where they have meaning:
:WILD - Wildcard match of one level of directory structure.
:WILD-INFERIORS - Wildcard match of any number of directory levels.
:UP - Go upward in directory structure (semantic).
:BACK - Go upward in directory structure (syntactic).
The difference between up and back is that if there is a directory
(:ABSOLUTE "X" "Y" "Z")
linked to
(:ABSOLUTE "A" "B" "C")
and there also exist directories
(:ABSOLUTE "A" "B" "Q")
(:ABSOLUTE "X" "Y" "Q")
then
(:ABSOLUTE "X" "Y" "Z" :OUT "Q")
designates
(:ABSOLUTE "A" "B" "Q")
while
(:ABSOLUTE "X" "Y" "Z" :UP "Q")
designates
(:ABSOLUTE "X" "Y" "Q")
Test Case:
(PATHNAME-DIRECTORY (PARSE-NAMESTRING "[FOO.BAR]BAZ.LSP")) ;on VMS
=> (:ABSOLUTE "FOO" "BAR")
(PATHNAME-DIRECTORY (PARSE-NAMESTRING "/foo/bar/baz.lisp")) ;on Unix
=> (:ABSOLUTE "foo" "bar")
or (:ABSOLUTE "FOO" "BAR")
If PATHNAME-COMPONENT-CASE:CANONICALIZE passes, only the 2nd return value.
(PATHNAME-DIRECTORY (PARSE-NAMESTRING ">foo>**>bar>baz.lisp")) ;on LispM
=> (:ABSOLUTE "FOO" :WILD-INFERIORS "BAR")
(PATHNAME-DIRECTORY (PARSE-NAMESTRING ">foo>*>bar>baz.lisp")) ;on LispM
=> (:ABSOLUTE "FOO" :WILD "BAR")
Rationale:
This would allow programs to usefully deal with hierarchical file systems,
which are by far the most common file system type.
Current Practice:
Symbolics Genera implements something very similar to this. The main
differences are:
- In Genera, there is no :ABSOLUTE keyword at the head of the list.
This has been shown to cause some problems in dealing with root
directories. Genera represents the root directory by a keyword
symbol (rather than a list) because the list representation
was not adequately general.
- Genera represents Unix ".." as :UP, but deals with :UP
syntactically, not semantically.
Cost to Implementors:
In principle, nothing about the implementation needs to change except
the treatment of the directory field by MAKE-PATHNAME and
PATHNAME-DIRECTORY. The internal representation can otherwise be left
as-is if necessary.
For implementations that choose to rationalize this representation
throughout their internals and any other implementation-specific
accessors, the cost will be necessarily higher.
Cost to Users:
None. This change is upward compatible.
Cost of Non-Adoption:
Serious portability problems would continue to occur. Programmers would be
driven to the use of implementation-specific facilities because the need
for this is frequently impossible to ignore.
Benefits:
The serious costs of non-adoption would be avoided.
Aesthetics:
This representation of hierarchical pathnames is easy to use and quite
general. Users will probably see this as an improvement in the aesthetics.
Discussion:
This issue was raised a while back but no one was fond of the particular
proposal that was submitted. This is an attempt to revive the issue.
The original proposal, to add a :SUBDIRECTORIES field to a pathname, was
discarded because it imposed an unnatural distinction between a toplevel
directory and its subdirectories. Pitman's guess is the the idea was to
try to make it a compatible change, but since most programmers will
probably want to change from implementation-specific primitives to portable
ones anyway, that's probably not such a big deal. Also, there might have
been some programs which thought the change was compatible and ended up
ignoring important information (the :SUBDIRECTORIES field). Pitman thought
it would be better if people just accepted the cost of an incompatible
change in order to get something really pretty as a result.
This issue used to address the issue of relative pathnames (pathnames
relative to some default which is separately maintained). Pitman removed
this issue for now in order to simplify things. He feels the issue should
be resubmitted under separate cover so that it can be discussed separately.
----- Next Message -----
Date: Thu, 29 Dec 88 13:29 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: PATHNAME-SUBDIRECTORY-LIST (Version 3)
To: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
cc: CL-Cleanup@SAIL.STANFORD.EDU
In-Reply-To: <881228143206.5.KMP@BOBOLINK.SCRC.Symbolics.COM>
I approve PATHNAME-SUBDIRECTORY-LIST:NEW-REPRESENTATION but note the
following typos and proposed simplifications. Also, don't you need
functions like Symbolics' DIRECTORY-PATHNAME-AS-FILE and
PATHNAME-AS-DIRECTORY? The conversion between the name of a directory
and the directory component of a file inferior to that directory is
system-dependent, for example TOPS-20 appends a type field and Unix does
not. Also in some systems the root directory has a name and in others
it doesn't. Of course these functions signal an error in
non-hierarchical file systems. Should there be a separate proposal for
these?
Typos (and some discussion):
Problem Description:
- In some implementations "FOO.BAR" might denote the "BAR" subdirectory
of "FOO" while in other implementations because "." is not the
separator.
Some words must be missing after "while".
Proposal (PATHNAME-SUBDIRECTORY-LIST:NEW-REPRESENTATION)
:UP - Go upward in directory structure (semantic).
:BACK - Go upward in directory structure (syntactic).
The difference between up and back is that if there is a directory
(:ABSOLUTE "X" "Y" "Z")
linked to
(:ABSOLUTE "A" "B" "C")
and there also exist directories
(:ABSOLUTE "A" "B" "Q")
(:ABSOLUTE "X" "Y" "Q")
then
(:ABSOLUTE "X" "Y" "Z" :OUT "Q")
designates
(:ABSOLUTE "A" "B" "Q")
while
(:ABSOLUTE "X" "Y" "Z" :UP "Q")
designates
(:ABSOLUTE "X" "Y" "Q")
Is :OUT a typo for :BACK? Also I don't understand what your proposed
semantic/syntactic distinction is. I almost thought I did until I read
the above text carefully and saw that the syntactic one chases links
to the truename and the semantic one does not, which seems backwards.
I also don't think :UP and :BACK are meaningful anywhere except immediately
after :RELATIVE, although I have to concede that Unix disagrees with me
and therefore Symbolics Genera's Unix pathname support also disagrees
with me. But if they were only allowed immediately after :RELATIVE I
don't think you would need two of them. I also don't think that
MERGE-PATHNAMES should ever look at what files/directories actually
exist in the file system, which makes me opposed to the existence
of the one that you have called syntactic. Is this really something
we need, or will TRUENAME do the job?
I think we should only have :UP and not :BACK.
Current Practice:
- Genera represents Unix ".." as :UP, but deals with :UP
syntactically, not semantically.
After you straighten out the definition of syntactic and semantic, check
whether this statement is true. (I'm always irked by proposals where
the current practice section is wrong, because someone wrote an original
proposal where the current practice section was right, then the group
changed the proposal all around but didn't update the current practice
section).
Discussion:
This issue used to address the issue of relative pathnames (pathnames
relative to some default which is separately maintained). Pitman removed
this issue for now in order to simplify things. He feels the issue should
be resubmitted under separate cover so that it can be discussed separately.
It seems to me that this fully addresses relative pathnames already. The
discussion of :UP and :BACK (if freed of typos) seems specific enough that
even though this proposal doesn't explicitly propose what MERGE-PATHNAMES
does with relative pathnames, I think there is only one thing that it could
do that would be consistent. A pathname with a :RELATIVE directory is
not very different from a pathname with a NIL directory; in either case
you have to merge with a default to find the real directory to use; thus
I don't think there are any other new issues with relative pathnames.
----- Next Message -----
Date: Thu, 29 Dec 88 14:54 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: PATHNAME-SUBDIRECTORY-LIST (Version 3)
To: Moon@STONY-BROOK.SCRC.Symbolics.COM
cc: KMP@STONY-BROOK.SCRC.Symbolics.COM, CL-Cleanup@SAIL.STANFORD.EDU
In-Reply-To: <19881229182903.0.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Thu, 29 Dec 88 13:29 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
... don't you need functions like Symbolics' DIRECTORY-PATHNAME-AS-FILE and
PATHNAME-AS-DIRECTORY? The conversion between the name of a directory
and the directory component of a file inferior to that directory is
system-dependent, for example TOPS-20 appends a type field and Unix does
not. Also in some systems the root directory has a name and in others
it doesn't. Of course these functions signal an error in
non-hierarchical file systems. Should there be a separate proposal for
these? ...
I guess it's enough related to this topic that it could piggy back.
Certainly these functions made no sense prior to this proposal and
now they are suddenly important, so I'll see about putting them in on
next pass.
... Is :OUT a typo for :BACK? ...
Yeah. Sloppy editing. Sorry.
Also I don't understand what your proposed semantic/syntactic
distinction ...
Semantic means you have to probe the file system. Syntactic means
looking at the file names themselves is enough. Maybe I screwed up
the presentation. I'll double-check.
Genera is syntactic in that it doesn't probe when processing :UP.
That means that MERGE-PATHNAMES on
(:ABSOLUTE "X" "Y" "Z")
and
(:RELATIVE :UP "Q")
returns
(:ABSOLUTE "X" "Y" "Q")
rather than
(:ABSOLUTE "X" "Y" "Z" :UP "Q")
If you were going to contract out the :UP, you'd need to probe the
file system to make sure
(:ABSOLUTE "A" "B" "Q")
wasn't more correct than
(:ABSOLUTE "X" "Y" "Q")
so I think Genera has a bug.
I think this because if I do:
cd /m/n/o
cd ../q
on Unix I get one place, but in Genera if I visit a file in the
editor named
/m/n/o/x.lisp
and then I type c-X c-F and when prompted for a filename I type
../q/x.lisp
I end up with
/m/n/o/q/x.lisp
rather than the x.lisp in the directory that Unix itself would have
plopped me in if I'd used the cd commands above.
If you disagree, please reply to me privately so we can avoid
further confusion, quickly iron it out offline, and then report a
joint answer (and rationale) to everyone else once we've achieved
consensus.
I also don't think :UP and :BACK are meaningful anywhere except immediately
after :RELATIVE, although I have to concede that Unix disagrees with me
and therefore Symbolics Genera's Unix pathname support also disagrees
with me.
When I previously raised this topic, there were a pile of messages on
exactly this subject. My putting these into the proposal was an attempt
to address those topics. Even if I took these out, the current proposal
offers the flexibility that implementations could offer them without being
in violation of the spec. On the other hand, if people -are- going to offer
them, we might as well agree on common names if it's possible to do so.
But if they were only allowed immediately after :RELATIVE I
don't think you would need two of them.
I claim my example above refutes this.
I also don't think that
MERGE-PATHNAMES should ever look at what files/directories actually
exist in the file system,
If you permit :UP in absolute pathnames, you don't have to look in the
file system. You just get some funny names. Most file systems that
have this feature permit such funny names, though. eg, /foo/../bar/x
is valid in Unix, I understand. If memory serves me, Multics permits
>foo>bar>baz<x>y in Multics, no? Our (Symbolics) pathname system doesn't
permit embedded "<", but the error message suggests that this is only
because there's no obvious interpretation. We could define it to mean
:BACK rather than :UP, so that syntactic merges could be done and
unique pathnames would always be generated.
which makes me opposed to the existence
of the one that you have called syntactic.
In any case, I'm sympathetic to your desire to not look in the file
system. I just think that if a file system designer has made a
decision that forces you to look in the file system to get the right
answer, I don't know what we the CL designers can do to alter that.
The same issue comes up for logical devices and as Sandra has reminded
us, we've not done a particularly good job of papering over that real
externally-induced issue either.
Is this really something we need, or will TRUENAME do the job?
TRUENAME and OPEN would, presumably, not return pathnames with :UP
references (except maybe in pathological situations which they tell
me you can make in Unix if you try hard enough where the only way to
get to a directory is to go down first and then dig upward.)
I think we should only have :UP and not :BACK.
Nothing forces a file system to have both. The question is whether
there are some file systems that have one set of semantics and others
which have the other. If so, then two tokens are needed. In the discussion
leading up to this, people asserted (and I took them at their word) that
there were such competing semantics.
Current Practice:
- Genera represents Unix ".." as :UP, but deals with :UP
syntactically, not semantically.
After you straighten out the definition of syntactic and semantic, check
whether this statement is true. (I'm always irked by proposals where
the current practice section is wrong, because someone wrote an original
proposal where the current practice section was right, then the group
changed the proposal all around but didn't update the current practice
section).
I'll double-check when I've made the next version.
Discussion:
This issue used to address the issue of relative pathnames (pathnames
relative to some default which is separately maintained). Pitman removed
this issue for now in order to simplify things. He feels the issue should
be resubmitted under separate cover so that it can be discussed separately.
It seems to me that this fully addresses relative pathnames already. The
discussion of :UP and :BACK (if freed of typos) seems specific enough that
even though this proposal doesn't explicitly propose what MERGE-PATHNAMES
does with relative pathnames, I think there is only one thing that it could
do that would be consistent. A pathname with a :RELATIVE directory is
not very different from a pathname with a NIL directory; in either case
you have to merge with a default to find the real directory to use; thus
I don't think there are any other new issues with relative pathnames.
Well, there was the whole treatment of :UP. I hadn't really meant for this
proposal to specify that treatment so much as to identify a common representation
so we'd be a little less divergent in the areas we hadn't really specified.
Does anyone think I should add a disclaimer in the proposal body similar to the
one for :OLDEST, :INSTALLED, etc in pathname versions in CLtL that says that
although these are semi-standard names, there is no attached semantics?
----- Next Message -----
Date: Thu, 29 Dec 88 16:05 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: PATHNAME-SUBDIRECTORY-LIST (Version 3)
To: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
cc: CL-Cleanup@SAIL.STANFORD.EDU
In-Reply-To: <881229145413.6.KMP@BOBOLINK.SCRC.Symbolics.COM>
Date: Thu, 29 Dec 88 14:54 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Date: Thu, 29 Dec 88 13:29 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Also I don't understand what your proposed semantic/syntactic
distinction ...
Semantic means you have to probe the file system. Syntactic means
looking at the file names themselves is enough. Maybe I screwed up
the presentation. I'll double-check.
OK, I understand, and you did screw up the presentation.
But if they were only allowed immediately after :RELATIVE I
don't think you would need two of them.
I claim my example above refutes this.
Agreed.
I also don't think that
MERGE-PATHNAMES should ever look at what files/directories actually
exist in the file system,
If you permit :UP in absolute pathnames, you don't have to look in the
file system. You just get some funny names. Most file systems that
have this feature permit such funny names, though. eg, /foo/../bar/x
is valid in Unix, I understand. If memory serves me, Multics permits
>foo>bar>baz<x>y in Multics, no?
No. Although that's from memory: there are few Multices left, I don't
have an account of any of them, and my manuals are in the attic at home.
I think you got syntactic and semantic mixed up again. I think you're
saying that MERGE-PATHNAMES of a relative directory against an absolute
directory will remove :UP, since that's purely syntactic, but will leave
:BACK in the middle of the merged directory, since resolving :BACK
"semantically" would require accessing the file system, which
MERGE-PATHNAMES doesn't do. Okay.
These names are extremely confusing, obviously. Can anyone think
of better ones than :UP and :BACK?
Our (Symbolics) pathname system doesn't
permit embedded "<", but the error message suggests that this is only
because there's no obvious interpretation.
The error message I get doesn't suggest anything, it's just "Embedded <?".
We could define it to mean
:BACK rather than :UP, so that syntactic merges could be done and
unique pathnames would always be generated.
I don't understand this sentence. Say it again after we all agree on
which one is :UP and which one is :BACK.
which makes me opposed to the existence
of the one that you have called syntactic.
In any case, I'm sympathetic to your desire to not look in the file
system. I just think that if a file system designer has made a
decision that forces you to look in the file system to get the right
answer, I don't know what we the CL designers can do to alter that.
The same issue comes up for logical devices and as Sandra has reminded
us, we've not done a particularly good job of papering over that real
externally-induced issue either.
Is this really something we need, or will TRUENAME do the job?
TRUENAME and OPEN would, presumably, not return pathnames with :UP
references (except maybe in pathological situations which they tell
me you can make in Unix if you try hard enough where the only way to
get to a directory is to go down first and then dig upward.)
I think we should only have :UP and not :BACK.
Nothing forces a file system to have both. The question is whether
there are some file systems that have one set of semantics and others
which have the other. If so, then two tokens are needed. In the discussion
leading up to this, people asserted (and I took them at their word) that
there were such competing semantics.
I don't know enough about the weird file systems out there to dispute this.
Well, there was the whole treatment of :UP. I hadn't really meant for this
proposal to specify that treatment so much as to identify a common representation
so we'd be a little less divergent in the areas we hadn't really specified.
Does anyone think I should add a disclaimer in the proposal body similar to the
one for :OLDEST, :INSTALLED, etc in pathname versions in CLtL that says that
although these are semi-standard names, there is no attached semantics?
Yes, I think :UP and :OLDEST have the same status, but no I don't agree
that that status is that they have no semantics. I agree with what CLtL
page 412 actually says, which is that either an implementation doesn't
support these keywords or if it does support them they have prescribed
meanings.
----- Next Message -----
Date: Thu, 29 Dec 88 14:48:23 PST
From: Jim McDonald <jlm@lucid.com>
To: Moon@STONY-BROOK.SCRC.Symbolics.COM
Cc: KMP@STONY-BROOK.SCRC.Symbolics.COM, CL-Cleanup@SAIL.STANFORD.EDU
In-Reply-To: David A. Moon's message of Thu, 29 Dec 88 13:29 EST
Subject: Issue: PATHNAME-SUBDIRECTORY-LIST (Version 3)
>> Is this really something we need, or will TRUENAME do the job?
If you're trying to create a filename to be used for output, it might
not exist yet (hence TRUENAME would signal an error), but there might
be various funny links in its directory path you would like to
traverse. Presumably you could use PROBE-FILE on some part of the
name (perhaps recursively down through the super-directories), then
merge in the remaining part, but that seems enough error-prone to be
worth hiding.
BTW, I think the labelling of semantic/syntactix examples was reversed
in the proposal, independantly of :UP vs. :BACK.
jlm
----- End Forwarded Messages -----
∂15-Mar-89 0741 CL-Cleanup-mailer Re: Issue: PLUS-ABNORMAL (Version 1)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 15 Mar 89 07:41:36 PST
Received: from Semillon.ms by ArpaGateway.ms ; 15 MAR 89 07:33:42 PST
Date: 15 Mar 89 07:33 PST
From: masinter.pa@Xerox.COM
Subject: Re: Issue: PLUS-ABNORMAL (Version 1)
In-reply-to: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>'s message
of Wed, 8 Mar 89 14:14 EST
To: CL-Cleanup@SAIL.Stanford.EDU, skona%csilvax@hub.ucsb.edu
Message-ID: <890315-073342-3688@Xerox>
I agree with KMP's "... if we want to do anything with +, ++, etc. it may
be to say that they are reserved for the implementation to assign as it
sees fit, and to give only vague guidelines beyond that -- referring
people to the implementation's manual for specifics."
I'm uncomfortable "pinning" down +, ++ and +++, since they cannot be used
reasonably by any portable code.
The notion of "evaluation" and "aborting" is fairly complex when there are
separate read-eval-print loops, debuggers, etc. For example, it seemed
reasonable to update *, ** once the values had been computed but before
they had been printed, in the case that the printing was aborted. The
"input" variables (-, +, ++, ...) are updated immediately after READ,
however.
In fact, the situation was more complicated because of the addition of
interleaved history lists; the history list itself maintains a corrolated
input-output history in "prompt" order, while there's a global ("last
value") IT that is shared by all Execs. ("Prompt" order is different than
"input" order, since the event number in the history list is allocated at
the time the prompt is generated, rather than when the input is complete.)
At one time I wanted to push for removing +, ++, +++, - from the standard
completely for what might be called 'aesthetic' grounds. I think they are
the only symbols in CL with unrelated value & function interpretations, for
example.
∂15-Mar-89 0817 CL-Cleanup-mailer Cleanup Issue Status
Received: from Think.COM by SAIL.Stanford.EDU with TCP; 15 Mar 89 08:15:31 PST
Received: from fafnir.think.com by Think.COM; Wed, 15 Mar 89 11:08:57 EST
Return-Path: <gls@Think.COM>
Received: from verdi.think.com by fafnir.think.com; Wed, 15 Mar 89 11:10:06 EST
Received: by verdi.think.com; Wed, 15 Mar 89 11:06:53 EST
Date: Wed, 15 Mar 89 11:06:53 EST
From: Guy Steele <gls@Think.COM>
Message-Id: <8903151606.AA01268@verdi.think.com>
To: masinter.pa@xerox.com
Cc: chapman%aitg.DEC@decwrl.dec.com, cl-cleanup@sail.stanford.edu
In-Reply-To: masinter.pa@xerox.com's message of 14 Mar 89 15:35 PST <890314-153644-2132@Xerox>
Subject: Cleanup Issue Status
> >+ FUNCTION-COMPOSITION
> >Synopsis: Add new functions
> >Version 5, 10-Feb-89
> >Status: Passed (as amended) Jan 89 X3J13
> I know this is picky, but I thought it was decided to fail this one
> completely and amend TEST-NOT-IF-NOT (I believe that was the related
> issue).
-- you may be right. I wish we had minutes. I guess I'll stick by my
summary unless I hear otherwise.
My notes show that the COMPLEMENT function was accepted and
all other parts of the proposal failed.
--Guy
∂15-Mar-89 0845 CL-Cleanup-mailer Re: Cleanup Issue Status
Received: from multimax.encore.com by SAIL.Stanford.EDU with TCP; 15 Mar 89 08:45:15 PST
Received: from mist.encore.COM by multimax.encore.com with SMTP (5.61/25-eef)
id AA23362; Wed, 15 Mar 89 11:42:12 -0500
Received: from localhost by mist. (4.0/SMI-4.0)
id AA05621; Wed, 15 Mar 89 11:40:30 EST
Message-Id: <8903151640.AA05621@mist.>
To: Guy Steele <gls@Think.COM>
Cc: masinter.pa@xerox.com,
"chapman%aitg.DEC@decwrl.dec.com"@multimax.encore.com,
cl-cleanup@sail.stanford.edu
Subject: Re: Cleanup Issue Status
In-Reply-To: Your message of Wed, 15 Mar 89 11:06:53 -0500.
<8903151606.AA01268@verdi.think.com>
Date: Wed, 15 Mar 89 11:40:28 EST
From: Dan L. Pierson <pierson@mist.encore.com>
Date: Wed, 15 Mar 89 11:06:53 EST
From: Guy Steele <gls@Think.COM>
To: masinter.pa@xerox.com
Cc: chapman%aitg.DEC@decwrl.dec.com, cl-cleanup@sail.stanford.edu
Subject: Cleanup Issue Status
> >+ FUNCTION-COMPOSITION
> >Synopsis: Add new functions
> >Version 5, 10-Feb-89
> >Status: Passed (as amended) Jan 89 X3J13
> I know this is picky, but I thought it was decided to fail this one
> completely and amend TEST-NOT-IF-NOT (I believe that was the related
> issue).
-- you may be right. I wish we had minutes. I guess I'll stick by my
summary unless I hear otherwise.
My notes show that the COMPLEMENT function was accepted and
all other parts of the proposal failed.
--Guy
My memory agrees with Guy's notes. We did spend several sessions on
this one and the waters got rather muddy at times.
∂15-Mar-89 0921 CL-Cleanup-mailer Re: Cleanup Issue Status
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 15 Mar 89 09:21:37 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 557486; Wed 15-Mar-89 12:18:32 EST
Date: Wed, 15 Mar 89 12:18 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: Cleanup Issue Status
To: Dan L. Pierson <pierson@mist.encore.com>, Guy Steele <gls@Think.COM>,
masinter.pa@xerox.com, chapman%aitg.DEC@decwrl.dec.com
cc: cl-cleanup@sail.stanford.edu
In-Reply-To: <8903151640.AA05621@mist.>
Message-ID: <19890315171827.0.MOON@EUPHRATES.SCRC.Symbolics.COM>
Line-fold: No
My notes agree with Dan and Guy. It's complicated because the
COMPLEMENT portion of FUNCTION-COMPOSITION was moved into
TEST-NOT-IF-NOT by an amendment, which was where it was
actually passed. Back in FUNCTION-COMPOSITION, NEW-FUNCTIONS
was voted down unanimously and later COMPLEMENT-AND-CONSTANTLY
was voted down by something to something.
Date: Wed, 15 Mar 89 11:40:28 EST
From: Dan L. Pierson <pierson@mist.encore.com>
Date: Wed, 15 Mar 89 11:06:53 EST
From: Guy Steele <gls@Think.COM>
> >+ FUNCTION-COMPOSITION
> >Synopsis: Add new functions
> >Version 5, 10-Feb-89
> >Status: Passed (as amended) Jan 89 X3J13
> I know this is picky, but I thought it was decided to fail this one
> completely and amend TEST-NOT-IF-NOT (I believe that was the related
> issue).
-- you may be right. I wish we had minutes. I guess I'll stick by my
summary unless I hear otherwise.
My notes show that the COMPLEMENT function was accepted and
all other parts of the proposal failed.
--Guy
My memory agrees with Guy's notes. We did spend several sessions on
this one and the waters got rather muddy at times.
∂15-Mar-89 0930 CL-Cleanup-mailer Issue: PRETTY-PRINT-INTERFACE (Version 1)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 15 Mar 89 09:30:41 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 557494; Wed 15-Mar-89 12:28:19 EST
Date: Wed, 15 Mar 89 12:28 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: PRETTY-PRINT-INTERFACE (Version 1)
To: masinter.pa@Xerox.COM, Guy Steele <gls@Think.COM>
cc: cl-cleanup@sail.stanford.edu
In-Reply-To: <890314-170500-2365@Xerox>
Message-ID: <19890315172817.3.MOON@EUPHRATES.SCRC.Symbolics.COM>
Line-fold: No
If you're thinking about making a new version, I intend to comment on
this, but it's so huge that it's taking a long time. A very brief
summary of some of my likely comments is: I'm in favor of the general
idea of defining a standard pretty printer, but there are some problems
in the details of this proposal; part of this seems to resemble CLOS,
but is gratuitously(?) different; there doesn't seem to be any
concession to variable-width fonts, although I didn't find an explicit
statement of what units indentation and width are measured in; I wish to
God that Dick Waters hated FORMAT, because the grotesque FORMAT-based
syntax is going to make this a lot harder to pass.
∂15-Mar-89 0934 CL-Cleanup-mailer RE: Cleanup Issue Status
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 15 Mar 89 09:33:57 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 557496; Wed 15-Mar-89 12:30:17 EST
Date: Wed, 15 Mar 89 12:30 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: RE: Cleanup Issue Status
To: masinter.pa@Xerox.COM, chapman%aitg.DEC@decwrl.dec.com
cc: cl-cleanup@sail.stanford.edu
In-Reply-To: <890314-153644-2132@Xerox>
Message-ID: <19890315173018.4.MOON@EUPHRATES.SCRC.Symbolics.COM>
Line-fold: No
Date: 14 Mar 89 15:35 PST
From: masinter.pa@Xerox.COM
> >+ DECLARE-ARRAY-TYPE-ELEMENT-REFERENCES
> >Version 3, 13-Jan-89
> >Status: passed, Jan 89 X3J13
> I believe this one was amended.
-- I have no amendments marked. Do you know what the amendment was?
> >+ PEEK-CHAR-READ-CHAR-ECHO
> >Version 3, 8-Oct-88, Released 8 Oct 88
> >Synopsis: PEEK-CHAR, READ-CHAR on streams made by MAKE-ECHO-STREAM
> >Status: Passed, Jan 89 X3J13
> I have this marked as amended.
-- I have no amendments made at the meeting. Do you?
My notes from January don't show any amendments to either of these.
∂15-Mar-89 0936 CL-Cleanup-mailer Issue: ADJUST-ARRAY-NOT-ADJUSTABLE (Version 8)
Received: from Aquinas.Think.COM by SAIL.Stanford.EDU with TCP; 15 Mar 89 09:36:35 PST
Received: from OCCAM.THINK.COM by Aquinas.Think.COM via INTERNET with SMTP id 124413; 15 Mar 89 12:34:29 EST
Date: Wed, 15 Mar 89 12:34 EST
From: Barry Margolin <barmar@FAFNIR.THINK.COM>
Subject: Issue: ADJUST-ARRAY-NOT-ADJUSTABLE (Version 8)
To: cl-cleanup@sail.stanford.edu
cc: X3J13@sail.stanford.edu
In-Reply-To: <890315-051405-3472@Xerox>
Message-ID: <19890315173420.1.BARMAR@OCCAM.THINK.COM>
Date: 15 Mar 89 05:13 PST
From: masinter.pa@xerox.com
Proposal (ADJUST-ARRAY-NOT-ADJUSTABLE:CLARIFY):
Hooray! We finally got our collective acts together on this one!
barmar
∂15-Mar-89 0947 CL-Cleanup-mailer Issue: COPY-SYMBOL-PRINT-NAME
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 15 Mar 89 09:47:16 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 557507; Wed 15-Mar-89 12:44:21 EST
Date: Wed, 15 Mar 89 12:44 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: COPY-SYMBOL-PRINT-NAME
To: chapman%aitg.DEC@decwrl.dec.com
cc: cl-cleanup@sail.stanford.edu, skona%csilvax@hub.ucsb.edu
In-Reply-To: <8903151339.AA29246@decwrl.dec.com>
Message-ID: <19890315174412.5.MOON@EUPHRATES.SCRC.Symbolics.COM>
I like COPY-SYMBOL-PRINT-NAME:EQUAL.
∂15-Mar-89 0959 CL-Cleanup-mailer Issue: TIME-ZONE-NON-INTEGER
Received: from Think.COM by SAIL.Stanford.EDU with TCP; 15 Mar 89 09:59:06 PST
Received: from fafnir.think.com by Think.COM; Wed, 15 Mar 89 12:55:14 EST
Return-Path: <gls@Think.COM>
Received: from verdi.think.com by fafnir.think.com; Wed, 15 Mar 89 12:56:34 EST
Received: by verdi.think.com; Wed, 15 Mar 89 12:53:22 EST
Date: Wed, 15 Mar 89 12:53:22 EST
From: Guy Steele <gls@Think.COM>
Message-Id: <8903151753.AA02688@verdi.think.com>
To: chapman%aitg.DEC@decwrl.dec.com, cl-cleanup@sail.stanford.edu
In-Reply-To: David A. Moon's message of Tue, 14 Mar 89 16:55 EST <19890314215504.9.MOON@EUPHRATES.SCRC.Symbolics.COM>
Subject: Issue: TIME-ZONE-NON-INTEGER
I strongly support TIME-ZONE-NON-INTEGER:ALLOW.
∂15-Mar-89 0948 X3J13-mailer Issue: GENSYM-NAME-STICKINESS (Version 1)
Received: from Think.COM by SAIL.Stanford.EDU with TCP; 15 Mar 89 09:48:17 PST
Received: from fafnir.think.com by Think.COM; Wed, 15 Mar 89 12:44:45 EST
Return-Path: <gls@Think.COM>
Received: from verdi.think.com by fafnir.think.com; Wed, 15 Mar 89 12:46:05 EST
Received: by verdi.think.com; Wed, 15 Mar 89 12:42:51 EST
Date: Wed, 15 Mar 89 12:42:51 EST
From: Guy Steele <gls@Think.COM>
Message-Id: <8903151742.AA02653@verdi.think.com>
To: cl-cleanup@sail.stanford.edu
Cc: x3j13@sail.stanford.edu
In-Reply-To: masinter.pa@xerox.com's message of 14 Mar 89 14:56 PST <890314-145716-2049@Xerox>
Subject: Issue: GENSYM-NAME-STICKINESS (Version 1)
Does KMP intend that GENSYM not be sticky for an integer argument
as well? That is, there is no way to reset the counter?
--Guy
∂15-Mar-89 1045 CL-Cleanup-mailer Issue: GENSYM-NAME-STICKINESS (Version 1)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 15 Mar 89 10:45:16 PST
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 557570; Wed 15-Mar-89 13:42:53 EST
Date: Wed, 15 Mar 89 13:42 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: GENSYM-NAME-STICKINESS (Version 1)
To: gls@Think.COM
cc: CL-Cleanup@SAIL.Stanford.EDU
In-Reply-To: <8903151742.AA02653@verdi.think.com>
Message-ID: <890315134243.9.KMP@BOBOLINK.SCRC.Symbolics.COM>
[X3J13 removed.]
Date: Wed, 15 Mar 89 12:42:51 EST
From: Guy Steele <gls@Think.COM>
Does KMP intend that GENSYM not be sticky for an integer argument
as well? That is, there is no way to reset the counter?
The great thing about the idea of a writeup is that it can stand alone,
regardless of what the author thinks. The writeup is not ambiguous --
it takes away the ability to reset the counter.
Happily, that means I can disagree with the writeup without disagreeing
with myself. It's obvious now that I think about it, that taking away
the ability to reset the counter makes it nearly useless to be able to
affect the counter, since you cannot simultaneously pass a name and a
counter (probably a mistake itself), and since you'd always get the
same number unless you did (GENSYM (INCF *MY-COUNTER*)) or some such.
I myself have never used the gensym-counter-resetting feature. I
have to say I don't think a lot of people use it either. The only use
I can really think of is for resetting a system so that you can get
the same set of GENSYM names again in a second run to a bunch of code.
If we were going to permit that, I would rather just document the
variable that holds the counter and not have it be done as a side-effect
of calling the function.
My basic feeling is that the "easy use" of GENSYM is best satisfied
if only a name is permissible, and use of any other kind argument is
starting to get into hair that it best done by people rolling their own
using MAKE-SYMBOL, FORMAT, and INCF.
My inclination at this point would be to document a variable:
*GENSYM-COUNTER*
which held the GENSYM counter, and to say that GENSYM could only take
a name argument (leaving other situations "undefined" so that
implementations could provide a graceful transition), and to say the
name argument is not sticky.
However, the only part of this I really care about is that the name
not be sticky. If you make any reasonable counterproposal that gives
me that one feature, odds are that I'll support it.
∂15-Mar-89 1057 CL-Cleanup-mailer Issue LOOP-AND-DISCREPANCY, version 1
Received: from Think.COM by SAIL.Stanford.EDU with TCP; 15 Mar 89 10:56:37 PST
Received: from fafnir.think.com by Think.COM; Wed, 15 Mar 89 13:52:49 EST
Return-Path: <gls@Think.COM>
Received: from verdi.think.com by fafnir.think.com; Wed, 15 Mar 89 13:54:08 EST
Received: by verdi.think.com; Wed, 15 Mar 89 13:50:51 EST
Date: Wed, 15 Mar 89 13:50:51 EST
From: Guy Steele <gls@Think.COM>
Message-Id: <8903151850.AA02865@verdi.think.com>
To: cl-cleanup@sail.stanford.edu
Cc: gls@Think.COM
Subject: Issue LOOP-AND-DISCREPANCY, version 1
Issue: LOOP-AND-DISCREPANCY
References: Loop Facility document X3J13/89-004
Related issues:
Category: CHANGE CLARIFICATION
Edit history: Version 1, 15-Mar-88 by Steele
Problem description:
The treatment of the AND conjunction in FOR/AS and WITH clauses is not
consistent. Examples of the use of WITH are also not consistent in this
respect.
Page 2-5 implies by example that when AND is used to join two
FOR/AS clauses, the word FOR or AS must occur after the word AND.
Page 2-31 has formal syntax specifying that when AND is used to join two
WITH clauses, the word WITH must *not* occur after the word AND. Examples
on that page are consistent with this specification.
Page 2-41 has an example in which WITH is repeated after AND.
Proposal (LOOP-AND-DISCREPANCY:NO-REITERATION):
Let stand the formal syntax for WITH.
Change the description of FOR/AS clauses to specify that when
two or more such clauses are joined with AND, clauses after the
first do not have FOR or AS before them.
The complete formal syntax for FOR/AS may be described as follows:
for-as ::= {FOR | AS} for-as-subclause {AND for-as-subclause}*
for-as-subclause ::= for-as-arithmetic | for-as-in-list
| for-as-on-list | for-as-equals-then
| for-as-across | for-as-hash | for-as-package
for-as-arithmetic ::= var [type-spec] ...
and so on.
Examples:
> (loop for x from 1 to 10 ;Corrected from X3J13/89-004, page 2-5
and y = nil then x
collect (list x y))
((1 NIL) (2 1) (3 2) (4 3) (5 4) (6 5) (7 6) (8 7) (9 8) (10 9))
> (loop with (a b) float = '(1.0 2.0) ;Corrected from X3J13/89-004, page 2-41
and (c d) integer = '(3 4)
and (e f)
return (list a b c d e f))
(1.0 2.0 3 4 nil nil)
Rationale:
The treatment of AND should be internally consistent. There is no reason
to repeat the FOR/AS keyword. Not repeating the keyword emphasizes that
the subclauses are functionally linked under the heading of WITH or FOR.
(Compare to the third use of AND in LOOP, to link clauses controlled
by WHEN/IF/UNLESS. One does not repeat the WHEN; rather, the clauses
grouped by AND are controlled by a single WHEN.)
Current practice:
Symbolics LOOP allows FOR to be included or omitted after AND,
with identical meanings. WITH may not be repeated after AND.
Cost to Implementors: Small?
Cost to Users: Possible incompatibility with existing implementors' extensions.
Cost of non-adoption: Utter confusion.
Performance impact: None.
Benefits: Consistent treatment of AND within LOOP.
Esthetics:
Absolutely none. We're talking about LOOP here.
Discussion:
Steele supports this proposal. It is a reversal of his previous
suggestion on the topic, thanks to feedback from Moon.
∂15-Mar-89 1111 CL-Cleanup-mailer Issue: COPY-SYMBOL-COPY-PLIST
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 15 Mar 89 11:11:37 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 557610; Wed 15-Mar-89 14:09:10 EST
Date: Wed, 15 Mar 89 14:09 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: COPY-SYMBOL-COPY-PLIST
To: Masinter.pa@xerox.com
cc: Barry Margolin <barmar@Think.COM>, cl-cleanup@sail.stanford.edu
In-Reply-To: <19890110181742.7.BARMAR@OCCAM.THINK.COM>
Message-ID: <19890315190909.7.MOON@EUPHRATES.SCRC.Symbolics.COM>
Line-fold: No
This one was marked with a * on your status report, but I don't
think it was ever brought up to the committee, and I don't think
it needs amendment. The discussion was just over whether
it's really a cleanup issue or an editorial issue. Let's just
vote on it as-is.
∂15-Mar-89 1127 CL-Cleanup-mailer Issue: REAL-NUMBER-TYPE (version 3)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 15 Mar 89 11:27:06 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 557635; Wed 15-Mar-89 14:24:27 EST
Date: Wed, 15 Mar 89 14:24 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: REAL-NUMBER-TYPE (version 3)
To: Masinter.pa@xerox.com
cc: Robert A. Cassels <Cassels@STONY-BROOK.SCRC.Symbolics.COM>, CL-Cleanup@Sail.Stanford.EDU,
DySak@STONY-BROOK.SCRC.Symbolics.COM, JGA@STONY-BROOK.SCRC.Symbolics.COM,
Common-Lisp-Implementors@STONY-BROOK.SCRC.Symbolics.COM
In-Reply-To: <19890113185020.8.CASSELS@GROUSE.SCRC.Symbolics.COM>
Message-ID: <19890315192425.8.MOON@EUPHRATES.SCRC.Symbolics.COM>
Line-fold: No
Your issue status for this one says
* REAL-NUMBER-TYPE
Synopsis: add REAL = (OR RATIONAL FLOAT) & range
Version 2, 08-Jan-89
Comment: lengthy dissent; discussion? coercion for comparitor?
Status: need new version
but I think this version is ready to vote up-or-down. Note that
there are two proposals; the REALP predicate function has been
separated out from the REAL data type.
Date: Fri, 13 Jan 89 13:50 EST
From: Robert A. Cassels <Cassels@STONY-BROOK.SCRC.Symbolics.COM>
Issue: REAL-NUMBER-TYPE
Forum: CLEANUP
References: Table 4-1.
Category: ADDITION
Edit history: 04-JAN-89, Version 1 by Bob Cassels, Don Sakahara, Kent Pitman,
and John Aspinall
08-JAN-89, Version 2 by Bob Cassels -- incorporate
Masinter's suggestion and make REAL a CLOS class
13-JAN-89, Version 3 by Cassels and Aspinall -- incorporate Marc LeBrun's
suggestions clarifying the relationship between CL
numeric type names and mathematical names
Status: For Internal Discussion
Problem Description:
There is no standard type specifier symbol for the CL type
'(OR RATIONAL FLOAT).
Proposal (REAL-NUMBER-TYPE:REAL):
Make REAL be a CL data type:
p.13 "Numbers"
Add: The NUMBER data type encompasses all of these kinds of
numbers. For convenience, there are names for some
subclasses of numbers. @i[Integers] and @i[ratios] are of
type RATIONAL. @i[Rational numbers] and @[floating-point
numbers] are of type REAL. @i[Real numbers] and @i[complex
numbers] are of type NUMBER.
Although the names of these types were chosen with the
terminology of mathematics in mind, the correspondences
are not always exact. Integers and ratios model the
corresponding mathematical concepts directly. Numbers
of the FLOAT type may be used to approximate real
numbers, both rational and irrational. The REAL type
includes all Common Lisp numbers which represent
mathematical real numbers, though there are
mathematical real numbers (irrational numbers)
which do not have an exact Common Lisp representation.
Only REAL numbers may be ordered using the <, >, <=,
and >= functions.
Compatibility note: The Fortran standard defines the term
"real datum" to mean "a processor approximation to the value
of a real number." In practice the Fortran "basic real" type
is the floating-point data type Common Lisp calls
SINGLE-FLOAT. The Fortran "double precision" type is
Common Lisp's DOUBLE-FLOAT. The Pascal "real" data type is
an "implementation-defined subset of the real numbers." In
practice this is usually a floating-point type, often what
Common Lisp calls DOUBLE-FLOAT.
A translation of an algorithm written in Fortran or Pascal
which uses "real" data usually will use some appropriate
precision of Common Lisp's FLOAT type. Some algorithms may
gain accuracy and/or flexibility by using Common Lisp's
RATIONAL or REAL types instead.
p.33 "Overlap, Inclusion, and Disjointness of Types":
Remove: The types RATIONAL, FLOAT, and COMPLEX are pairwise
disjoint subtypes of NUMBER.
Rationale: It might be thought that INTEGER and RATIO ...
Rationale: It might be thought that FIXNUM and BIGNUM ...
Add: The types RATIONAL and FLOAT are pairwise disjoint subtypes
of REAL.
The types REAL and COMPLEX are pairwise disjoint subtypes
of NUMBER.
Rationale: It might be thought that FIXNUM and BIGNUM should
form an exhaustive partition of the type INTEGER, that INTEGER
and RATIO should form an exhaustive partition of RATIONAL,
that RATIONAL and FLOAT should form an exhaustive partition of
REAL, and that REAL and COMPLEX should form an exhaustive
partition of NUMBER. These are all purposely avoided in order
to permit compatible experimentation with extensions to the
Common Lisp number system, such as the idea of adding explicit
representations of infinity or of positive and negative infinity.
p.43 Table 4-1 "Standard Type Specifier Symbols"
Add: REAL
p.49 "Type Specifiers that Abbreviate"
Add: (REAL low high)
Denotes the set of real numbers between low and high. ...
[As with RATIONAL and FLOAT.]
Make REAL a built-in CLOS class.
Proposal (REAL-NUMBER-TYPE:REALP):
Add a specific data type predicate REALP which tests for membership in
this type. [By analogy with NUMBERP.]
Test Case:
If a programmer wishes to test for "a number between 1 and 10", the
only current CL types would be '(or (rational 1 10) (float 1 10)) or
something like '(and numberp (not complexp) (satisfies range-1-10))
with (defun range-1-10 (real) (<= 1 real 10)). Both of these are
likely less efficient, and certainly less expressive than '(real 1 10).
Rationale:
Mathematics has a name for (OR RATIONAL FLOAT) -- it is "real".
This class is important because it is all the numbers which can be
ordered.
Throughout the "Numbers" chapter, the phrase "non-complex number" is
used.
MAX, MIN, p. 198 "The arguments may be any non-complex numbers."
CIS p. 207 "The argument ... may be any non-complex number."
Current Practice:
Probably nobody does this.
Cost to Implementors:
Some work is necessary to add this name. But since the underlying
type already exists the amount of work should be minimal.
Cost to Users:
Since this is an upward-compatible extension, it may be ignored by
users.
Cost of Non-Adoption:
Occasional inconvenience and/or inefficiency.
Benefits:
Mathematical clarity.
Ability to do CLOS method dispatch on the type.
Aesthetics:
As mentioned under "rationale," this would be a more concise way to
express a common programming idiom.
Discussion:
The name "non-complex number" is incorrect because future
implementations may wish to include numerical types which are neither
complex nor real. [e.g. pure imaginary numbers or quaternions]
The name "scalar" is incorrect because the mathematical concept of
scalar may indeed include complex numbers.
Fortran and Pascal use the name "real" to mean what CL calls
SINGLE-FLOAT. That should cause no significant problem, since a Lisp
program written using the type REAL will do mathematically what the
equivalent Fortran program would do. This is because Fortran's "real"
data-type is a subtype of the CL REAL type. The only differences
might be that the Lisp program could be less efficient and/or more
accurate.
A survey of several Fortran and Pascal books shows that the distinction
between INTEGER and REAL is that REAL numbers may have fractional
parts, while INTEGERs do not. Later discussions explain that REALs
cover a greater range. Much later discussions cover precision
considerations, over/underflow, etc. So the average Fortran or Pascal
programmer should be completely comfortable with the proposed Lisp
concept of REAL.
∂15-Mar-89 1138 CL-Cleanup-mailer Issue: REMF-DESTRUCTION-UNSPECIFIED (Version 4)
Received: from Aquinas.Think.COM by SAIL.Stanford.EDU with TCP; 15 Mar 89 11:34:16 PST
Received: from OCCAM.THINK.COM by Aquinas.Think.COM via CHAOS with CHAOS-MAIL id 124421; Wed 15-Mar-89 13:58:59 EST
Date: Wed, 15 Mar 89 13:58 EST
From: Barry Margolin <barmar@FAFNIR.THINK.COM>
Subject: Issue: REMF-DESTRUCTION-UNSPECIFIED (Version 4)
To: masinter.pa@xerox.com
cc: kmp@symbolics.com, cl-cleanup@sail.stanford.edu
In-Reply-To: <890314-144336-2004@Xerox>
Message-ID: <19890315185842.5.BARMAR@OCCAM.THINK.COM>
Sorry for the delay. Here's a version with my amendments merged in.
Actually, it looks like it might read better if all the NCONC stuff were
pulled out of this proposal and made a separate issue; right now, most
of the sections say general things and then have a paragraph that begins
with "In the NCONC case...". In that case, I suggest that the text
Amemdment I from my 14 February mail be used verbatim as the proposal.
barmar
Issue: REMF-DESTRUCTION-UNSPECIFIED
References: (SETF (GET ...) ...), REMPROP, (SETF (GETF ...) ...),
REMF (pp165-167); NREVERSE (p248); DELETE, DELETE-IF,
DELETE-DUPLICATES, NSUBSTITUTE, NSUBSTITUTE-IF (pp254-256);
NCONC, NRECONC (p269); NUNION, NINTERSECTION,
NSET-EXCLUSIVE-OR (pp276-279).
Category: CLARIFICATION/CHANGE
Edit history: 11-Feb-87, Version 1 by Dave Andre (DLA@Symbolics.COM)
29-Oct-87, Version 2 by Pitman (flesh out proposals)
28-Nov-88, Version 3 by Pitman (revised presentation)
29-Nov-88, Version 4 by Pitman (slight editing per DLA)
15-Mar-89, Version 5 by Margolin (amendments discussed in
Hawaii, removed -NOT functions)
Status: For Internal Discussion
Problem Description:
Currently, the exact nature of the side-effect performed by list
modification routines is not specified.
Either the specific modifications allowed should be specified so that
programmers can rely on them and implementors can avoid accidentally
causing problems by introducing well-meaning optimizations, or else
the documentation should explicitly state that the effects are
unspecified so that programmers will not depend on them and
implementors will feel comfortable about doing interesting optimizations.
Proposal (REMF-DESTRUCTION-UNSPECIFIED:EXPLICITLY-VAGUE-EXCEPT-NCONC):
Clarify that the way in which the destructive behavior of the
operators below is achieved is explicitly vague in a number of ways,
in order to provide individual implementations the necessary
flexibility to do useful optimizations.
(SETF (GETF place indicator) value)
is permitted to either SETF place or to SETF any part, CAR or
CDR, of the top-level list structure held by that place.
(REMF place indicator)
is permitted to either SETF place or to SETF any part, CAR or
CDR, of the top-level list structure held by that place.
(SETF (GET symbol indicator) value)
is constrained to behave exactly the same as
(SETF (GETF (SYMBOL-PLIST symbol) indicator) value).
(REMPROP symbol indicator)
is constrained to behave exactly the same as
(REMF (SYMBOL-PLIST symbol) indicator).
(NREVERSE sequence)
when sequence is a list, is permitted to SETF any part, CAR or
CDR, of the top-level list structure in that sequence.
when sequence is an array is permitted to re-order the elements
of the given sequence in order to produce the resulting array.
(DELETE object sequence ...)
when sequence is a list, is permitted to SETF any part, CAR or
CDR, of the top-level list structure held in that sequence.
when sequence is an array is permitted to change the dimensions
of the array and to slide its elements into new positions without
permuting them to produce the resulting array.
(DELETE-IF test sequence ...)
is constrained to behave exactly like
(DELETE NIL sequence
:TEST #'(LAMBDA (IGNORE ITEM) (FUNCALL test ITEM))
...).
(DELETE-DUPLICATES sequence ...)
when sequence is a list, is permitted to SETF any part, CAR or
CDR, of the top-level list structure held in that sequence.
when sequence is an array is permitted to change the dimensions
of the array and to slide its elements into new positions without
permuting them to produce the resulting array.
(NSUBSTITUTE new-object old-object sequence ...)
(NSUBSTITUTE-IF new-object test sequence ...)
when sequence is a list, is permitted to SETF any part, CAR or
CDR, of the top-level list structure in that sequence.
when sequence is an array is permitted to SETF the contents of
any cell in that array which must be replaced by NEW-OBJECT.
Note, however, that since this side-effect is not required,
these functions should still not be used in for-effect-only
positions in portable code.
(NRECONC list tail)
is constrained to have side-effect behavior equivalent to:
(NCONC (NREVERSE list) tail).
(NUNION list1 list2 ...)
(NINTERSECTION list1 list2 ...)
(NSET-EXCLUSIVE-OR list1 list2 ...)
is permitted to SETF any part, CAR or CDR, of the top-level of
any of the given lists.
Note, however, that since this side-effect is not required,
these functions should still not be used in for-effect-only
positions in portable code.
(NCONC . lists)
is defined using the following recursive relationship:
(NCONC) => NIL
(NCONC NIL . args) == (NCONC . args)
(NCONC arg) => arg
(NCONC arg1 arg2) has the side effect of (RPLACD (LAST arg1) arg2),
and returns arg1
(NCONC arg1 arg2 . args) == (NCONC (NCONC arg1 arg2) . args)
[If a previous cleanup issue prohibited NIL as a non-last argument
then ignore the (NCONC NIL . args) case.]
Note: The above clarifications are not intended as complete functional
descriptions. They are intended to augment (rather than to replace)
other descriptions already in effect.
Test Cases:
For GETF...
(SETQ FOO (LIST 'A 'B 'C 'D 'E 'F)) ==> (A B C D E F)
(SETQ BAR (CDDR FOO)) ==> (C D E F)
(REMF FOO 'C)
BAR ==> ??
In Symbolics Common Lisp, BAR holds (C D E F).
CLtL allows other interpretations. eg, BAR might hold
(C), (NIL), (C NIL) or (C D).
Under this proposal, any of these interpretations (and others as well)
would still be valid
For DELETE...
(SETQ FOO (LIST 'A 'B 'C)) ==> (A B C)
(SETQ BAR (CDR FOO)) ==> (B C)
(SETQ FOO (DELETE 'B FOO)) ==> (A C)
BAR ==> ??
(EQ (CDR FOO) (CAR BAR)) ==> ??
In Symbolics Common Lisp, these last two expressions return ((C)) and T.
Under this proposal, either of these interpretations (and others
as well) would be valid.
For NCONC...
(SETQ FOO (LIST 'A 'B 'C 'D 'E)
BAR (LIST 'F 'G 'H 'I 'J)
BAZ (LIST 'K 'L 'M)) => (K L M)
(SETQ FOO (NCONC FOO BAR BAZ)) => (A B C D E F G H I J K L M)
FOO => (A B C D E F G H I J K L M)
BAR => (F G H I J K L M)
BAZ => (K L M)
(SETQ FOO (LIST 'A 'B 'C 'D 'E)
BAR (LIST 'F 'G 'H 'I 'J)
BAZ (LIST 'K 'L 'M)) => (K L M)
(SETQ FOO (NCONC NIL FOO BAR NIL BAZ)) => (A B C D E F G H I J K L M)
FOO => (A B C D E F G H I J K L M)
BAR => (F G H I J K L M)
BAZ => (K L M)
Rationale:
Implementations already vary widely on their implementation techniques
for these functions. This effectively clarifies the status quo, making
it more clear to programmers what they may rely upon in portable code.
In the case of NCONC, however, the precise definition is useful because
it is what users expect, it is how NCONC has been defined for many
years, and it is how current implementations generally work. It may
not always be the most efficient way (e.g. it may result in invisible
pointers in CDR-coded implementations), but callers of NCONC probably
use it specifically for its precise side effects.
Current Practice:
All valid implementations are believed to comply with the vague
definitions. Symbolics Genera 7.2 and Sun Common Lisp 2.1.3 appear to
conform to the NCONC spec.
Cost to Implementors:
None. This is probably the status quo for most implementors. If there
are any implementations that don't implement NCONC as above (which I
doubt) they will have to be changed.
Cost to Users:
This change would not affect programs coded with "good programming
practice". That is, only programs which rely on currently undocumented
features would be in any danger of breaking. In fact, those programs
are already in such danger, and this change to the documentation would
just publicize it. The clarification would -encourage- good programming
practice by warning people to only obey the published contract of the
above-mentioned functions.
There is, however, no automatic technique for making this check for
programs already in error. Bugs due to unexpected side-effects are in
general among the hardest to reckon with.
Cost of Non-Adoption:
Programmers may naively believe there is only one possible or reasonable
implementation of these functions. Some implementors may shy away from
reasonable optimizations out of a paranoid belief that deviating from
some vague, unspoken rules will lead to programmer unrest. Making these
things explicitly vague clarifies the implementor's rights in a way that
permits numerous useful optimizations.
Benefits:
Users would be discouraged from taking advantage of subtle details
of these destructive operations because such details would be explicitly
not guaranteed to be portable.
Implementations can improve performance of many of the above-mentioned
functions when they are not under the constraint to implement them
in a highly constrained fashion. For example, in Symbolics systems,
DELETE of a cdr-coded list could use the implementation primitive
%CHANGE-LIST-TO-CONS rather than RPLACD to avoid creating forwarding
pointers.
Garbage collection effectiveness can also be improved. For example,
all of the destructive operations which remove objects (eg, REMF)
could remove CAR pointers to removed objects which are more volatile
than the list itself, assisting the garbage collector and thereby
improving memory usage and paging performance.
Tightening the definition of NCONC permits users to predict their
programs' behavior more precisely.
Non-Benefits:
Users who inadvertently depend on side-effect behavior may be rudely
surprised when moving between implementations.
Compatibility with older Lisp dialects is diminished.
Implementors have less flexibility in implementing NCONC efficiently.
Performance Impact:
Metering in Symbolics test systems have shown that there are substantial
performance gains to be had by allowing implementations flexibility in
these areas.
In the case of NCONC, this implementation flexibility, and hence
potential performance improvements, is sacrificed.
Aesthetics:
Most of these functions implement abstract operations. For example,
REMPROP implements an abstract operation on a "property list".
Proper language design should not encourage people to delve below the
level of abstraction into the nitty gritty.
NCONC is a "less abstract" function than the rest of the functions
described above. It is usually used precisely because of the way it
interacts with list implementation.
Discussion:
Andre's original version of this proposal pushed for explicitly vague
descriptions of these functions' side-effect behavior. He believes
that if users want more predictability from these functions, they
should write private variants that implement whatever predictability
they require.
Pitman originally opposed this position because he weighed portability
a higher concern. Since the original discussion, however, his views on
how to resolve this priority have been refined, and he now believes
that leaving things vague is appropriate. As such, he now supports what
is effectively Andre's original proposal.
Pitman and Andre supported version 4. [I don't know how they feel
about v5 -- Barmar].
∂15-Mar-89 1145 CL-Cleanup-mailer Issue: REAL-NUMBER-TYPE (version 3)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 15 Mar 89 11:44:52 PST
Received: from GROUSE.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 557688; Wed 15-Mar-89 14:42:23 EST
Date: Wed, 15 Mar 89 14:42 EST
From: Robert A. Cassels <Cassels@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: REAL-NUMBER-TYPE (version 3)
To: Moon@STONY-BROOK.SCRC.Symbolics.COM, Masinter.pa@xerox.com
cc: Cassels@STONY-BROOK.SCRC.Symbolics.COM, CL-Cleanup@Sail.Stanford.EDU,
DySak@STONY-BROOK.SCRC.Symbolics.COM, JGA@STONY-BROOK.SCRC.Symbolics.COM,
Common-Lisp-Implementors@STONY-BROOK.SCRC.Symbolics.COM
In-Reply-To: <19890315192425.8.MOON@EUPHRATES.SCRC.Symbolics.COM>
Message-ID: <19890315194221.4.CASSELS@GROUSE.SCRC.Symbolics.COM>
Date: Wed, 15 Mar 89 14:24 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Your issue status for this one says
* REAL-NUMBER-TYPE
Synopsis: add REAL = (OR RATIONAL FLOAT) & range
Version 2, 08-Jan-89
Comment: lengthy dissent; discussion? coercion for comparitor?
Status: need new version
but I think this version is ready to vote up-or-down. Note that
there are two proposals; the REALP predicate function has been
separated out from the REAL data type.
Date: Fri, 13 Jan 89 13:50 EST
From: Robert A. Cassels <Cassels@STONY-BROOK.SCRC.Symbolics.COM>
Issue: REAL-NUMBER-TYPE
Forum: CLEANUP
References: Table 4-1.
Category: ADDITION
Edit history: 04-JAN-89, Version 1 by Bob Cassels, Don Sakahara, Kent Pitman,
and John Aspinall
08-JAN-89, Version 2 by Bob Cassels -- incorporate
Masinter's suggestion and make REAL a CLOS class
13-JAN-89, Version 3 by Cassels and Aspinall -- incorporate Marc LeBrun's
suggestions clarifying the relationship between CL
numeric type names and mathematical names
Status: For Internal Discussion
We should change "current practice" to note that TI Lisp includes both
the REAL type and REALP predicate.
∂15-Mar-89 1147 CL-Cleanup-mailer Issue: MAKE-STRING-FILL-POINTER (Version 1)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 15 Mar 89 11:47:34 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 557698; Wed 15-Mar-89 14:45:08 EST
Date: Wed, 15 Mar 89 14:45 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: MAKE-STRING-FILL-POINTER (Version 1)
To: Masinter.pa@xerox.com
cc: CL-Cleanup@sail.stanford.edu
In-Reply-To: <19881021012549.3.MOON@KENNETH-WILLIAMS.SCRC.Symbolics.COM>
Message-ID: <19890315194500.9.MOON@EUPHRATES.SCRC.Symbolics.COM>
Line-fold: No
Your status file says:
* MAKE-STRING-FILL-POINTER
Synopsis: extend MAKE-STRING to take a fill-pointer?
Version 1, 20-Oct-88
Comments: extend to take other keywords? MAKE-STRING should return
simple string always? Interaction with character proposal
Status: awaiting new version
But I don't have any record of any discussion that would warrant
a new version. Also I don't believe the comments quoted above
are relevant to this issue. If you have any discussion I should
see, and suggestions for a new version, could you forward them to
me? If you send me that I'll make a new version. Otherwise I
think the old version is ready to vote on, up-or-down.
Date: Thu, 20 Oct 88 21:25 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Issue: MAKE-STRING-FILL-POINTER
References: CLtL p.302
Related issues: none that I know of
Category: ADDITION
Edit history: Version 1, 20-Oct-88, by Moon, for discussion
Problem description:
Once again I lost because I expected to be able to use MAKE-STRING
to create a string with a fill-pointer, and I couldn't. I had to use
a more long-winded MAKE-ARRAY call instead.
Proposal (MAKE-STRING-FILL-POINTER:ALLOW):
Give MAKE-STRING a :FILL-POINTER argument, with the same syntax and
semantics as the :FILL-POINTER argument to MAKE-ARRAY.
Examples:
(make-string 80 :fill-pointer 0)
Test Cases:
See examples.
Rationale:
I frequently expect it to be allowed and am surprised when it's not.
Current practice:
I know of no implementations that support this.
Cost to Implementors:
5 cents.
Cost to Users:
none
Cost of non-adoption:
none
Performance impact:
none
Benefits:
Increased language consistency.
Esthetics:
Increased language consistency.
Discussion:
Other MAKE-ARRAY options that one might want to allow, but are
not already allowed or proposed, are :INITIAL-CONTENTS, :ADJUSTABLE,
:DISPLACED-TO, and :DISPLACED-INDEX-OFFSET. A strong case could be
made for :ADJUSTABLE (I use an implementation where it doesn't matter,
so I don't care about that), I don't think anyone would care about the
other three.
∂15-Mar-89 1208 CL-Cleanup-mailer Issue status
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 15 Mar 89 12:07:44 PST
Received: by decwrl.dec.com (5.54.5/4.7.34)
id AA29800; Wed, 15 Mar 89 12:05:27 PST
Message-Id: <8903152005.AA29800@decwrl.dec.com>
Received: by decwrl.dec.com (5.54.5/4.7.34)
for cl-cleanup@sail.stanford.edu; id AA29800; Wed, 15 Mar 89 12:05:27 PST
From: chapman%aitg.DEC@decwrl.dec.com
Date: 15 Mar 89 14:29
To: cl-cleanup@sail.stanford.edu
Subject: Issue status
> > >+ FUNCTION-COMPOSITION
> > >Synopsis: Add new functions
> > >Version 5, 10-Feb-89
> > >Status: Passed (as amended) Jan 89 X3J13
> > I know this is picky, but I thought it was decided to fail this one
> > completely and amend TEST-NOT-IF-NOT (I believe that was the related
> > issue).
>
> -- you may be right. I wish we had minutes. I guess I'll stick by my
> summary unless I hear otherwise.
>
>My notes show that the COMPLEMENT function was accepted and
>all other parts of the proposal failed.
Yes but COMPLEMENT was an amendment to TEST-NOT-IF-NOT. This was how Walter
and I both recorded it. Anyway, it seems to be clear what happened even
if the status of the issues isn't.
∂15-Mar-89 1227 CL-Cleanup-mailer Re: issue PROCLAIM-LEXICAL (Version 9)
Received: from NSS.Cs.Ucl.AC.UK by SAIL.Stanford.EDU with TCP; 15 Mar 89 12:26:28 PST
Received: from aiai.edinburgh.ac.uk by NSS.Cs.Ucl.AC.UK via Janet with NIFTP
id aa11885; 15 Mar 89 20:13 GMT
Date: Wed, 15 Mar 89 20:10:25 GMT
Message-Id: <2348.8903152010@subnode.aiai.ed.ac.uk>
From: Jeff Dalton <jeff%aiai.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK>
Subject: Re: issue PROCLAIM-LEXICAL (Version 9)
To: masinter.pa@xerox.com, cl-cleanup@sail.stanford.edu
In-Reply-To: masinter.pa@com.xerox's message of 13 Mar 89 17:14 PST
> The last version of PROCLAIM-LEXICAL I have is Version 9, which was
> distributed before the Hawaii meeting. There were the various comments on
> Version 9, amendments proposed but not passed, and, more recently, mail
> from Sandra Loosemore, Jeff Dalton, JonL White, Gail Zacharias and David
> Moon.
>
> However, there's no new version.
Last I knew, JonL had said there were "conceptual" problems. I said
that, if there were, I didn't understand what they were. And that was
the last I saw on this topic. Maybe I'd managed to convince JonL?
In Hawaii, some people objected on grounds of efficiency or because
they didn't have a spare bit (see the Rees suggestion in the
proposal).
I think the ammendments proposed in Hawaii might have answered both
kinds of objection, but I remember thinking that some of the
ammendments were unnecessary or wrong.
Perhaps those who still have objections can say what they would like
to change and why.
∂15-Mar-89 1229 CL-Cleanup-mailer Re: Issue: READ-CASE-SENSITIVITY (Version 1)
Received: from NSS.Cs.Ucl.AC.UK by SAIL.Stanford.EDU with TCP; 15 Mar 89 12:27:33 PST
Received: from aiai.edinburgh.ac.uk by NSS.Cs.Ucl.AC.UK via Janet with NIFTP
id aa09545; 15 Mar 89 15:59 GMT
Date: Wed, 15 Mar 89 15:57:02 GMT
Message-Id: <1423.8903151557@subnode.aiai.ed.ac.uk>
From: Jeff Dalton <jeff%aiai.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK>
Subject: Re: Issue: READ-CASE-SENSITIVITY (Version 1)
To: Kent M Pitman <KMP@scrc-stony-brook.arpa>, Masinter.PA@xerox.com
In-Reply-To: Kent M Pitman's message of Tue, 14 Mar 89 20:43 EST
Cc: CL-Cleanup@sail.stanford.edu
> All in all, though, I like somebody's (Gray's?) suggestion of a
> function rather than a table. The default being #'CHAR-UPCASE, and
> #'IDENTITY being another obvious choice.
It was indeed Gray's suggestion.
I also prefer the function to the keyword. However, can we allow
arbitrary functions or would that cause problems for the printer?
> The reason I like the function rather than the keyword is that you
> don't have to initially provide the alternate functionality -- user's
> can add it.
Can they or do the functions have to be from a set known to the
printer?
> In the case of the keyword, it has to be given by the system so you're
> at the mercy of the implementors as to which options you get. I think
> this feature is worth the added complexity.
I am somewhat uneasy about allowing arbitrary translations rather
than just having a case switch. I would rather have the general
mechanism but not if it would cause prople to oppose an issue they
would otherwise support.
-- Jeff
∂15-Mar-89 1256 CL-Cleanup-mailer PRETTY-PRINT-INTERFACE, version 3 (supersedes 2 sent an hour ago!)
Received: from Think.COM by SAIL.Stanford.EDU with TCP; 15 Mar 89 12:54:51 PST
Received: from fafnir.think.com by Think.COM; Wed, 15 Mar 89 15:50:57 EST
Return-Path: <gls@Think.COM>
Received: from verdi.think.com by fafnir.think.com; Wed, 15 Mar 89 15:52:16 EST
Received: by verdi.think.com; Wed, 15 Mar 89 15:49:04 EST
Date: Wed, 15 Mar 89 15:49:04 EST
From: Guy Steele <gls@Think.COM>
Message-Id: <8903152049.AA03416@verdi.think.com>
To: cl-cleanup@sail.stanford.edu
Subject: PRETTY-PRINT-INTERFACE, version 3 (supersedes 2 sent an hour ago!)
Version 3 is changed from version 1 as follows:
adds a functional interface to supplement the interface through FORMAT,
and reflects comments by Barrett and Pierson.
The document attached to version 1 has been omitted here, as the
mailer choked on it. It should logically be inserted before the
functional interface attached here.
--Guy
Issue: PRETTY-PRINT-INTERFACE
References: Description of XP by Dick Waters (attached)
*PRINT-PRETTY* (CLtL p. 371)
WRITE (CLtL p. 382)
PPRINT (CLtL p. 383)
FORMAT (CLtL pp. 385-407)
FORMAT ~T directive (CLtL pp. 398-399)
FORMAT ~< directive (CLtL pp. 404-406)
Related issues:
Category: CLARIFICATION CHANGE ADDITION
Edit history: Version 1, 24-Feb-89 by Steele
Version 2, 15-Mar-89 by Steele and Waters
Version 3, 15-Mar-89 by Steele
Problem description:
At present Common Lisp provides no specification whatsoever of how
pretty-printing is to be accomplished, and no way for the user to control
it. In particular, there is no protocol by which a user can write a
print-function for a structure, or a method for PRINT-OBJECT, that will
interact smoothly with the built-in pretty-printer in a portable manner.
Proposal (PRETTY-PRINT-INTERFACE:XP):
Adopt the interfaces and protocols of the XP pretty-printer by Dick Waters,
described in full in the attached 12-page document. Here is a very brief
summary of the proposal.
New variables: *PRINT-DISPATCH*
*PRINT-RIGHT-MARGIN*
*DEFAULT-RIGHT-MARGIN*
*PRINT-MISER-WIDTH*
*PRINT-LINES*
*LAST-ABBREVIATED-PRINTING*
New function: COPY-PRINT-DISPATCH
New macro: DEFINE-PRINT-DISPATCH
New FORMAT directives: ~W ~_ ~I ~:T ~/name/ ~<...~:>
New # reader macro: #"..."
The function WRITE is extended to accept additional keyword arguments
:DISPATCH, :RIGHT-MARGIN, :LINES, and :MISER-WIDTH corresponding to the
first four of the new variables.
Finally, wherever in the attached document it says that certain constructs
support depth abbreviation and circularity detection, it should be noted
that this is so a fortiori, because *all* printing operations support them
properly. Therefore, while the statements are correct, the possibly
misleading implication that they are the only way to achieve such
detection should be rectified if the text is taken over into the standard.
Examples: See attached document.
Rationale:
There ought to be a good user interface to the pretty printer.
This is the only proposal for which there is a portable implementation
that has seen extensive use and is being made freely available.
Current practice:
XP son of PP son of GPRINT son of PRINT* is the latest in a line of pretty
printers that goes back 13 years. All of these printers use essentially
the same basic algorithm and conceptual interface. Further, except for
PRINT*, which was implemented solely to satisfy the author's personal
needs, each of these printers has had extensive use. XP has been in
experimental use as the pretty printer in CMU Common Lisp for 6 months. PP
has been the pretty printer in DEC Common Lisp for the past 3 years. Prior
to three years ago, GPRINT was used for 2 years as the pretty printer in
DEC Common Lisp. In addition, GPRINT has been the pretty printer in
various generations of Symbolics Lisp for upwards of 5 years.
(See Waters R.C., "User Format Control in a Lisp Prettyprinter", ACM TOPLAS,
5(4):513--531, October 1983.)
Cost to Implementors:
A fair amount of effort (perhaps a few man-weeks at most).
Source code for XP is available to all comers from Dick Waters, and
the system is documented in great detail:
Waters, Richard C., "XP: A Common Lisp Pretty Printing System",
Artificial Intelligence Laboratory Technical Memo 1102,
Massachusetts Institute of Technology, Cambridge MA, March 1989.
Cost to Users: None (I think). This is an upward-compatible extension.
Cost of non-adoption: Continued inability for user print-functions
to interact with the pretty-printer in a useful and portable manner.
Performance impact: XP is claimed to be quite fast.
Benefits: User control of pretty-printing in a portable manner.
Esthetics:
Using ~<...~:> may strike some as uncomfortably close in the syntactic
space of FORMAT directives to the existing ~<...~>. However, it is very
unlikely that both of these directives (pretty-print logical block and
columnar justification, respectively) will be used in the same call to
FORMAT. Previous versions of XP used ~!...~. instead of ~<...~:> but this
made FORMAT strings very difficult to read; it is preferable to have
a directive that looks like matching brackets of some sort.
Dan Pierson comments: You might mention that some people will undoubtedly
find piling more hair on FORMAT ugly (of course these same people may
well find FORMAT in general ugly :-)).
Discussion:
Zetalisp used ~:T to mean pixelwise tabulation, so the use of ~:T
suggested here may be a problem. If so, another suggestion for naming
this directive would be appropriate.
The ~/.../ directive is already in Zetalisp, and is not an idea new
to this proposal.
Guy Steele and Dick Waters strongly support this proposal. (As an example,
Guy Steele has a portable simulator for Connection Machine Lisp, and would
like very much to have xappings and xectors pretty-print properly.)
Dan Pierson comments: You can add me to the list of strong supporters of
this proposal. While the proposal is long and complex, it is supported by
a long history of usage in several different Lisp environments. Unlike
some earlier members of this family, this version fits cleanly enough into
the rest of Common Lisp to warrant standardization.
The utility of *PRINT-LINES* becomes more obvious if it is pointed out
that Dick's pretty printers are implemented to print each line as it
is computed. This means that a small value for *PRINT-LINES* saves
significant time as well as output medium space. In fact, many people
find that a very pleasant REP loop is created by setting *PRINT-LINES*
to a value from 1-4, *PRINT-PRETTY* to T, and defining a short-name
function (say (PP*)) that funcalls *LAST-ABBREVIATED-PRINTING* with
abbreviation bound off. This is almost as fast and compact as, and
MUCH more readable than, a non-pretty-printing REP loop.
The advantages of compiled format strings (format functions) should be
brought out as benefits in their own right. The current proposal just
mentions them as a minor feature of XP.
At first this struck me a very cute end run around the failure of
STREAM-INFO, then I realized that one of the problems with STREAM-INFO
may have been that it was a standard at the wrong level. STREAM-INFO
permitted people to use XP, but not to count on it. This proposal
makes it possible to write portable code whose new data structures and
language elements print correctly in whatever Common Lisp environment
they're run in. [End of comments by Pierson]
!
Functional Interface
The primary interface to operations for dynamically determining the
arrangement of output is provided through FORMAT. This is done,
because FORMAT strings are typically the most convenient way of
interacting with pretty printing. However, these operations have
nothing inherently to do with FORMAT per se. In particular, they can
also be accessed via the six functions and macros below.
WITHIN-LOGICAL-BLOCK (&KEY :STREAM :VAR :ARG [Macro]
:PREFIX :PER-LINE-PREFIX :SUFFIX)
&BODY BODY
In the manner of ~<...~:>, this macro causes printing to be
grouped into a logical block. The value NIL is always returned.
:STREAM specifies the stream the logical block is to be printed on.
:STREAM defaults to *STANDARD-OUTPUT* and follows the standard
conventions for stream arguments to output functions---NIL stands for
*STANDARD-OUTPUT* and T stands for *TERMINAL-IO*.
:VAR (which defaults to *STANDARD-OUTPUT*) must be a symbol other than
T or NIL. :VAR is bound to a special kind of stream that supports
dynamic decisions about the arrangement of output.
The BODY can contain any arbitrary Lisp forms. All the standard
printing functions (e.g., WRITE, PRINC, TERPRI) can be used to print
output into :VAR. All and only the output sent to :VAR is treated as
being in the logical block. It is an error for the BODY to send any
output directly to :STREAM.
:SUFFIX (which defaults to the null string) specifies a suffix that is
printed just after the logical block. :PREFIX specifies a prefix to be
printed before the beginning of the logical block. :PER-LINE-PREFIX
specifies a prefix that is printed before the block and at the
beginning of each new line in the block. It is an error for :PREFIX
and :PRE-LINE-PREFIX to both be used. If neither is used, a :PREFIX of
the null string is assumed.
:ARG (which defaults to NIL) is interpreted as being a list that BODY
is responsible for printing. If :ARG is not a list, it is printed
using WRITE. If *PRINT-CIRCLE* is not NIL and :ARG is a circular
reference to a cons, then an appropriate #n# marker is printed. If
*PRINT-LEVEL* is not NIL and the logical block is at a dynamic nesting
depth of greater than *PRINT-LEVEL* in logical blocks, # is printed.
If either of the three conditions above occures, the special output is
printed on :STREAM and the BODY is skipped along with the printing of
the prefix and suffix.
CONDITIONAL-NEWLINE KIND &OPTIONAL (STREAM *STANDARD-OUTPUT*) [Function]
CONDITIONAL-NEWLINE is the functional equivalent of ~_. STREAM (which
defaults to *STANDARD-OUTPUT*) follows the standard conventions for
stream arguments to printing functions. The KIND argument specifies
the style of conditional newline. It must be one of :LINEAR, :FILL,
:MISER, or :MANDATORY. If STREAM is a special stream bound by
WITHIN-LOGICAL-BLOCK, a conditional newline is sent to it. Otherwise,
CONDITIONAL-NEWLINE has no effect. The value NIL is always returned.
LOGICAL-BLOCK-INDENT KIND N &OPTIONAL (STREAM *STANDARD-OUTPUT*) [Function]
LOGICAL-BLOCK-INDENT is the functional equivalent of ~I, STREAM
argument (which defaults to *STANDARD-OUTPUT*) follows the standard
conventions for stream arguments to printing functions. N specifies
the amount of indentation. If KIND is :FROM-START, this indentation is
relative to the start of the enclosing block (as for ~I). If KIND is
:FROM-POSITION, the indentation is relative to the current output
position (as for ~:I). It is an error for KIND to take on any other
value. If STREAM is a special stream bound by WITHIN-LOGICAL-BLOCK,
LOGICAL-BLOCK-INDENT sets the indentation in the innermost enclosing
logical block. Otherwise, LOGICAL-BLOCK-INDENT has no effect. The
value NIL is always returned.
LOGICAL-BLOCK-TAB KIND COLNUM COLINC &OPTIONAL (STREAM *STANDARD-OUTPUT*)
LOGICAL-BLOCK-TAB is the functional equivalent of ~T. STREAM (which
defaults to *STANDARD-OUTPUT*) follows the standard conventions for
stream arguments to printing functions. The arguments COLNUM and
COLINC correspond to the two numeric parameters to ~T. The KIND
argument specifies the style of tabbing. It must be one of :LINE (tab
using ~T), :BLOCK (tab using ~:T), :LINE-RELATIVE (tab using ~@T), or
:BLOCK-RELATIVE (tab using ~:@T). If STREAM is a special stream bound
by WITHIN-LOGICAL-BLOCK, tabbing is performed. Otherwise,
LOGICAL-BLOCK-TAB has no effect. The value NIL is always returned.
LOGICAL-BLOCK-POP ARGS &OPTIONAL (STREAM *STANDARD-OUTPUT*) [Macro]
LOGICAL-BLOCK-COUNT &OPTIONAL (STREAM *STANDARD-OUTPUT*) [Macro]
LOGICAL-BLOCK-POP is identical to POP except that it supports
*PRINT-LENGTH* and *PRINT-CIRCLE*. It is an error to use
LOGICAL-BLOCK-POP anywhere other than syntactically nested within a
call on WITHIN-LOGICAL-BLOCK.
ARGS must be a symbol or expression acceptable to POP. STREAM (which
defaults to *STANDARD-OUTPUT*) follows the standard conventions for
stream arguments to printing functions. If STREAM is a special stream
bound by WITHIN-LOGICAL-BLOCK, then LOGICAL-BLOCK-POP performs the
special operations described below. Otherwise, LOGICAL-BLOCK-POP is
identical to POP.
Each time LOGICAL-BLOCK-POP is called, it performs three tests. if
ARGS is not a cons, ". " is printed followed by ARGS. If
*PRINT-LENGTH* is NIL and LOGICAL-BLOCK-POP has already been called
*PRINT-LENGTH* times within the immediately containing logical block,
"..." is printed. If *PRINT-CIRCLE* is not NIL, and ARGS is a circular
reference, then ". " is printed followed by an appropriate #n# marker.
If either of the three conditions above occurs, the special output is
printed on :STREAM and the execution of the immediately containing
WITHIN-LOGICAL-BLOCK is terminated except for the printing of the
suffix. Otherwise, LOGICAL-BLOCK-POP pops the top value off of ARGS
and returns this value.
LOGICAL-BLOCK-COUNT is identical to LOGICAL-BLOCK-POP except that it
does not take an ARGS argument, always returns NIL, and only performs
the second test discussed above. It is useful when the components of a
non-list are being printed.
Using the functions above, TABULAR-STYLE could be defined as follows.
(defun tabular-style (stream list &optional (colon? T) atsign?
(tabsize nil))
(declare (ignore atsign?))
(if (null tabsize) (setq tabsize 16))
(within-logical-block (:var s :stream stream :arg list
:prefix (if colon? "(" "")
:suffix (if colon? ")" ""))
(when list
(loop (write (logical-block-pop list s) :stream s)
(if (null list) (return nil))
(write-char #\space s)
(logical-block-tab :block-relative 0 tabsize s)
(conditional-newline :fill s)))))
The function below prints a vector using #(...) notation.
(defun print-vector (v *standard-output*)
(within-logical-block (:prefix "#(" :suffix ")")
(let ((end (length v)) (i 0))
(when (plusp end)
(loop (logical-block-count)
(write (aref v i))
(if (= (incf i) end) (return nil))
(write-char #\space)
(conditional-newline :fill))))))
[End of attached document]
∂15-Mar-89 1306 CL-Cleanup-mailer Issue: GENSYM-NAME-STICKINESS, version 2
Received: from Think.COM by SAIL.Stanford.EDU with TCP; 15 Mar 89 13:05:38 PST
Received: from fafnir.think.com by Think.COM; Wed, 15 Mar 89 16:01:40 EST
Return-Path: <gls@Think.COM>
Received: from verdi.think.com by fafnir.think.com; Wed, 15 Mar 89 16:02:59 EST
Received: by verdi.think.com; Wed, 15 Mar 89 15:59:47 EST
Date: Wed, 15 Mar 89 15:59:47 EST
From: Guy Steele <gls@Think.COM>
Message-Id: <8903152059.AA03501@verdi.think.com>
To: cl-cleanup@sail.stanford.edu
Subject: Issue: GENSYM-NAME-STICKINESS, version 2
Cc: gls@Think.COM
Version 2 proposes to provide access to the counter state.
Additional Comments include:
"... it's ... late to consider things like this ..."
"YAY!!! This is what "cleanup" is for. Go For It! "
"Sounds like a good idea to me."
!
Issue: GENSYM-NAME-STICKINESS
Forum: Cleanup
References: GENSYM (p169)
Category: CHANGE
Edit history: 14-Feb-89, Version 1 by Pitman
15-Mar-89, Version 2 by Steele
Problem Description:
Many people avoid use of the argument to GENSYM because the argument
is `sticky' and such stickiness can lead to confusion. The problem is
that if any application (usually a macro) uses the gensym argument at
all, then all applications are forced to. If they do not, they risk
finding that the `helpful' argument supplied in some previous call will
be harmful to them.
Proposal (GENSYM-NAME-STICKINESS:WASH-HANDS):
Define that if an optional argument is given to GENSYM, it does NOT
have a side-effect on GENSYM's internal state.
Define that the function GENSYM-COUNTER takes a non-negative integer n
and modifies the internal state of GENSYM so that the next symbol
generated will be number n. GENSYM-COUNTER returns the old value
of the counter.
Rationale:
Conscientious programmers are forced now to write their own GENSYM
lookalikes because they know the system's GENSYM has an invasive
effect. This defeats the primary intended function of GENSYM, which
is to satisfy the most common idiomatic use of MAKE-SYMBOL.
The stickiness of the GENSYM prefix was an attempt to be gratuitously
compatible with Maclisp, at the expense of good programming pratice.
Users who need the old behavior of GENSYM can trivially implement
that behavior using MAKE-SYMBOL.
Occasionally you want to reset the GENSYM counter so that, for example,
you can get the compiler to generate the same symbol names again
(good for comparing results to see what really changed).
Test Case:
(CHAR-EQUAL (CHAR (SYMBOL-NAME (SECOND (LIST (GENSYM "A") (GENSYM)))) 0)
#\G)
=> NIL ;under CLtL
=> T ;under this proposal
(string= (symbol-name (progn (gensym-counter 43) (gensym "foo")))
"foo43") => T
Current Practice:
Symbolics Cloe and Genera are compatible with CLtL, so this would be an
incompatible change.
Cost to Implementors:
Very small.
Cost to Users:
Most uses of GENSYM do not depend on the stickiness of the name, so the
change would be compatible. In some cases, the change would be an
improvement. Even in the worst case where someone depends on stickiness,
it's extremely straightforward to write the couple of lines of code to
produce an application based on MAKE-SYMBOL that is at least as flexible
as GENSYM, and often moreso.
Cost of Non-Adoption:
Good programmers would avoid using the argument to GENSYM (or using
GENSYM altogether) in many situations where they ought not have to.
Benefits:
Gensyms which appear to convey information through their name would not
accidentally pop out and cause confusion in places where they oughtn't.
Aesthetics:
Unnecessary global state changes are hard to reason about. This would
be a small simplification.
Discussion:
Pitman claims to have written a non-sticky GENSYM function for nearly
every one of the dozen or so large systems that he's written or worked
on in the last decade in order to get around the stated problem.
Others have suggested similar experience.
Pitman supported version 1. In response to a query, he said:
"... the only part of this I really care about is that the name
not be sticky. If you make any reasonable counterproposal that gives
me that one feature, odds are that I'll support it."
Steele supports this proposal.
∂15-Mar-89 1449 CL-Cleanup-mailer Issue SUBTYPEP-TOO-VAGUE, version 5
Received: from Think.COM by SAIL.Stanford.EDU with TCP; 15 Mar 89 14:46:57 PST
Received: from fafnir.think.com by Think.COM; Wed, 15 Mar 89 17:43:08 EST
Return-Path: <gls@Think.COM>
Received: from verdi.think.com by fafnir.think.com; Wed, 15 Mar 89 17:44:28 EST
Received: by verdi.think.com; Wed, 15 Mar 89 17:41:16 EST
Date: Wed, 15 Mar 89 17:41:16 EST
From: Guy Steele <gls@Think.COM>
Message-Id: <8903152241.AA03730@verdi.think.com>
To: cl-cleanup@sail.stanford.edu
Subject: Issue SUBTYPEP-TOO-VAGUE, version 5
Cc: gls@Think.COM
This is a proposed amendment to version 4 passed in January 1989 at Kauai.
Issue: SUBTYPEP-TOO-VAGUE
References: CLtL p. 72-73
Category: CLARIFICATION
Edit History: Version 1, 11 Jul 1988 (Sandra Loosemore)
Version 2, 19 Jul 1988 (Sandra Loosemore)
Version 3, 6-Oct-88 (Masinter)
Version 4, 7-Oct-88 (Masinter, per Moon's comments)
Problem Description:
[From version 4]
The description of SUBTYPEP allows it to return a second value of NIL
when the relationship between the two types cannot be determined. In
some cases this is a reasonable thing to do because it is impossible
to tell (if the SATISFIES type specifier is involved), and in other
cases the relationships between types are not well-defined (for
example, the VALUES type specifier or the list form of the FUNCTION
type specifier).
Some implementations, however, have apparently interpreted this to
mean that it is permissible for SUBTYPEP to "give up" and return a
second value of NIL in some cases where it actually would be possible
to determine the relationship. This makes it difficult to depend on
subtype relationships in portable code.
[Addition for version 5]
There are two problems with version 4. First is that of the first three
bulleted points in the version 4 proposal:
* Clarify that SUBTYPEP will return a second value of NIL
only when either of the type specifiers involves the SATISFIES, NOT,
AND, OR, MEMBER. SUBTYPEP will not return a second
value of NIL when both arguments involve only the words in Table 4-1, or
names of DEFSTRUCT- or DEFCLASS-defined types, or user-defined deftypes
that expand into only those words and/or names.
* SUBTYPEP should signal an error when handed (for either argument)
a type specifier that involves VALUES or the list form of the FUNCTION
type.
* SUBTYPEP must always return values T T in the case where the two
type specifiers (or their expansions) are EQUAL.
any two have significant overlap, and indeed all three can overlap;
version 4 contained no indication of how this conflict should be resolved.
Second is that version 4 calls for SUBTYPEP to signal an error (at least at
high safety)even when the arguments are valid type specifiers, but this can
make it harder to use SUBTYPEP. These are cases that returning NIL NIL
was supposed to cover.
This version replaces the three bulleted points above with a single point
and some observations about its consequences. This version eliminates
the requirement to signal an error.
Proposal: SUBTYPEP-TOO-VAGUE:CLARIFY-MORE
A type specifier "involves" a word like SATISFIES, MEMBER, NOT, etc.
if it either contains it directly or as the result of expansion of a
DEFTYPE defined type specifier.
* Clarify that SUBTYPEP is permitted to return NIL NIL only when
at least one argument involves SATISFIES, AND, OR, NOT, MEMBER,
VALUES, or the list form of FUNCTION.
Note that one consequence of this is that if neither argument
involves any of these type specifiers, then SUBTYPEP is obliged
to determine the relationship accurately. In particular, SUBTYPEP
must return T T if the arguments are EQUAL and do not involve
any of the above-stated type specifiers.
* Clarify that the relationships between types reflected by SUBTYPEP
are those specific to the particular implementation. For example, if
an implementation supports only a single type of floating-point numbers,
in that implementation (SUBTYPEP 'FLOAT 'LONG-FLOAT) would return T T
(since the two types would be identical).
Rationale:
Specifying the behavior of SUBTYPEP makes it more useful. Otherwise,
programs cannot rely on any more than NIL NIL as return values.
It is generally conceded that it is impossible to determine the
relationships between types defined with the SATISFIES specifier.
MEMBER, AND, OR, and NOT are messy to deal with.
Current Practice:
The implementation of SUBTYPEP in (the original) HPCL does not try to
expand type specifiers defined with DEFTYPE and does not recognize
EQUAL type specifiers as being equivalent. Most other implementations
appear to be substantially in conformance with the proposal.
Cost to implementors:
Some implementations will have to rewrite and/or extend parts of SUBTYPEP.
Cost to users:
Its hard to imagine a portable program that depends heavily
on SUBTYPEP. This proposal does not require any implementation
to "handle" fewer cases of SUBTYPEP.
Benefits:
An area of confusion in the language is cleared up. Usages of SUBTYPEP
will be more portable.
Discussion:
The handling of FLOAT and SINGLE-FLOAT appeared to be the
consensus from a discussion on the common-lisp mailing list some
time ago.
It would not be too onerous to require implementations to handle
the cases where one but not the other type specifier involves
OR, AND, NOT or MEMBER, but the specification becomes
cumbersome.
A related issue is clarifying what kinds of type specifiers must be
recognized by functions such as MAKE-SEQUENCE and COERCE. For example,
HPCL complains that (SIMPLE-ARRAY (UNSIGNED-BYTE *) (*)) is not a valid
sequence type when passed to MAKE-SEQUENCE, although SUBTYPEP does
recognize it to be a subtype of SEQUENCE. Should this proposal be
extended to deal with these issues, or is another proposal in order?
The rules for comparing the various type specifiers (such as ARRAY)
need to be spelled out in detail.
∂15-Mar-89 1454 CL-Cleanup-mailer [gls: Issue SUBTYPEP-TOO-VAGUE, version 5]
Received: from Think.COM by SAIL.Stanford.EDU with TCP; 15 Mar 89 14:50:43 PST
Received: from fafnir.think.com by Think.COM; Wed, 15 Mar 89 17:46:14 EST
Return-Path: <gls@Think.COM>
Received: from verdi.think.com by fafnir.think.com; Wed, 15 Mar 89 17:47:25 EST
Received: by verdi.think.com; Wed, 15 Mar 89 17:44:14 EST
Date: Wed, 15 Mar 89 17:44:14 EST
From: Guy Steele <gls@Think.COM>
Message-Id: <8903152244.AA03741@verdi.think.com>
To: cl-cleanup@sail.stanford.edu
Subject: [gls: Issue SUBTYPEP-TOO-VAGUE, version 5]
[I forgot to update the edit history. Here is corrected copy.]
Date: Wed, 15 Mar 89 17:41:16 EST
From: Guy Steele <gls>
To: cl-cleanup@sail.stanford.edu
Subject: Issue SUBTYPEP-TOO-VAGUE, version 5
Cc: gls
This is a proposed amendment to version 4 passed in January 1989 at Kauai.
Issue: SUBTYPEP-TOO-VAGUE
References: CLtL p. 72-73
Category: CLARIFICATION
Edit History: Version 1, 11 Jul 1988 (Sandra Loosemore)
Version 2, 19 Jul 1988 (Sandra Loosemore)
Version 3, 6-Oct-88 (Masinter)
Version 4, 7-Oct-88 (Masinter, per Moon's comments)
Version 5, 15-Mar-89 Steele
Problem Description:
[From version 4]
The description of SUBTYPEP allows it to return a second value of NIL
when the relationship between the two types cannot be determined. In
some cases this is a reasonable thing to do because it is impossible
to tell (if the SATISFIES type specifier is involved), and in other
cases the relationships between types are not well-defined (for
example, the VALUES type specifier or the list form of the FUNCTION
type specifier).
Some implementations, however, have apparently interpreted this to
mean that it is permissible for SUBTYPEP to "give up" and return a
second value of NIL in some cases where it actually would be possible
to determine the relationship. This makes it difficult to depend on
subtype relationships in portable code.
[Addition for version 5]
There are two problems with version 4. First is that of the first three
bulleted points in the version 4 proposal:
* Clarify that SUBTYPEP will return a second value of NIL
only when either of the type specifiers involves the SATISFIES, NOT,
AND, OR, MEMBER. SUBTYPEP will not return a second
value of NIL when both arguments involve only the words in Table 4-1, or
names of DEFSTRUCT- or DEFCLASS-defined types, or user-defined deftypes
that expand into only those words and/or names.
* SUBTYPEP should signal an error when handed (for either argument)
a type specifier that involves VALUES or the list form of the FUNCTION
type.
* SUBTYPEP must always return values T T in the case where the two
type specifiers (or their expansions) are EQUAL.
any two have significant overlap, and indeed all three can overlap;
version 4 contained no indication of how this conflict should be resolved.
Second is that version 4 calls for SUBTYPEP to signal an error (at least at
high safety)even when the arguments are valid type specifiers, but this can
make it harder to use SUBTYPEP. These are cases that returning NIL NIL
was supposed to cover.
This version replaces the three bulleted points above with a single point
and some observations about its consequences. This version eliminates
the requirement to signal an error.
Proposal: SUBTYPEP-TOO-VAGUE:CLARIFY-MORE
A type specifier "involves" a word like SATISFIES, MEMBER, NOT, etc.
if it either contains it directly or as the result of expansion of a
DEFTYPE defined type specifier.
* Clarify that SUBTYPEP is permitted to return NIL NIL only when
at least one argument involves SATISFIES, AND, OR, NOT, MEMBER,
VALUES, or the list form of FUNCTION.
Note that one consequence of this is that if neither argument
involves any of these type specifiers, then SUBTYPEP is obliged
to determine the relationship accurately. In particular, SUBTYPEP
must return T T if the arguments are EQUAL and do not involve
any of the above-stated type specifiers.
* Clarify that the relationships between types reflected by SUBTYPEP
are those specific to the particular implementation. For example, if
an implementation supports only a single type of floating-point numbers,
in that implementation (SUBTYPEP 'FLOAT 'LONG-FLOAT) would return T T
(since the two types would be identical).
Rationale:
Specifying the behavior of SUBTYPEP makes it more useful. Otherwise,
programs cannot rely on any more than NIL NIL as return values.
It is generally conceded that it is impossible to determine the
relationships between types defined with the SATISFIES specifier.
MEMBER, AND, OR, and NOT are messy to deal with.
Current Practice:
The implementation of SUBTYPEP in (the original) HPCL does not try to
expand type specifiers defined with DEFTYPE and does not recognize
EQUAL type specifiers as being equivalent. Most other implementations
appear to be substantially in conformance with the proposal.
Cost to implementors:
Some implementations will have to rewrite and/or extend parts of SUBTYPEP.
Cost to users:
Its hard to imagine a portable program that depends heavily
on SUBTYPEP. This proposal does not require any implementation
to "handle" fewer cases of SUBTYPEP.
Benefits:
An area of confusion in the language is cleared up. Usages of SUBTYPEP
will be more portable.
Discussion:
The handling of FLOAT and SINGLE-FLOAT appeared to be the
consensus from a discussion on the common-lisp mailing list some
time ago.
It would not be too onerous to require implementations to handle
the cases where one but not the other type specifier involves
OR, AND, NOT or MEMBER, but the specification becomes
cumbersome.
A related issue is clarifying what kinds of type specifiers must be
recognized by functions such as MAKE-SEQUENCE and COERCE. For example,
HPCL complains that (SIMPLE-ARRAY (UNSIGNED-BYTE *) (*)) is not a valid
sequence type when passed to MAKE-SEQUENCE, although SUBTYPEP does
recognize it to be a subtype of SEQUENCE. Should this proposal be
extended to deal with these issues, or is another proposal in order?
The rules for comparing the various type specifiers (such as ARRAY)
need to be spelled out in detail.
∂15-Mar-89 1756 CL-Cleanup-mailer Re: Issue LOCALLY-TOP-LEVEL, v1
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 15 Mar 89 17:56:39 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 15 MAR 89 17:24:03 PST
Date: 15 Mar 89 17:23 PST
From: masinter.pa@Xerox.COM
Subject: Re: Issue LOCALLY-TOP-LEVEL, v1
In-reply-to: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>'s message
of Mon, 13 Mar 89 18:51 EST
To: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
cc: Kim A. Barrett <IIM%ECLA@ECLC.USC.EDU>, cl-cleanup@SAIL.STANFORD.EDU,
cl-compiler@SAIL.STANFORD.EDU
Message-ID: <890315-172403-1288@Xerox>
I don't care what committee you send it to, but since Sandra has already
finished her list of proposals and I'm still working on mine, you might as
well get it on mine. Cleanup has more time, anyway.
It looked like it only needed the minor edit to fix the NO-HOSTING
allusion.
∂15-Mar-89 1907 CL-Cleanup-mailer Re: Issue STREAM-ACCESS
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 15 Mar 89 19:06:57 PST
Received: from Semillon.ms by ArpaGateway.ms ; 15 MAR 89 18:33:15 PST
Date: 15 Mar 89 18:31 PST
From: masinter.pa@Xerox.COM
Subject: Re: Issue STREAM-ACCESS
In-reply-to: Kim A. Barrett <IIM@ECLA.USC.EDU>'s message of Fri, 10 Mar 89
14:41:53 PST
To: Kim A. Barrett <IIM@ECLA.USC.EDU>
cc: cl-cleanup@SAIL.STANFORD.EDU
Message-ID: <890315-183315-1621@Xerox>
I don't think we want either
(typecase stream
(two-way-stream ...)
(echo-stream ...)
to behave in an implementation-dependent manner, or
to require that echo-stream be a subtype of two-way-stream.
You can always have a class that is their mutual
superclass, i.e., that they both inherit from.
However, the relation between the streams in
echo and two-way is significantly different.
∂16-Mar-89 0523 CL-Cleanup-mailer Re: Issue: GENSYM-NAME-STICKINESS, version 2
Received: from RELAY.CS.NET by SAIL.Stanford.EDU with TCP; 16 Mar 89 05:23:07 PST
Received: from relay2.cs.net by RELAY.CS.NET id ab00401; 16 Mar 89 8:13 EST
Received: from draper.com by RELAY.CS.NET id aa08495; 16 Mar 89 8:10 EST
Date: Thu, 16 Mar 89 07:58 EST
From: "Steve Bacher (Batchman)" <SEB1525@draper.com>
Subject: Re: Issue: GENSYM-NAME-STICKINESS, version 2
To: cl-cleanup@SAIL.STANFORD.EDU
X-VMS-To: CL-CLEANUP,SEB1525
I like it. But one suggestion:
Instead of (gensym-counter <n>) which updates the gensym counter, why not
(gensym-counter) which returns the current gensym counter, and
(setf (gensym-counter) <n>) ???
∂16-Mar-89 0646 CL-Cleanup-mailer Issue: GENSYM-NAME-STICKINESS, version 2
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 16 Mar 89 06:46:44 PST
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 558309; Thu 16-Mar-89 09:44:17 EST
Date: Thu, 16 Mar 89 09:44 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: GENSYM-NAME-STICKINESS, version 2
To: GLS@Think.COM
cc: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <890316094401.9.KMP@BOBOLINK.SCRC.Symbolics.COM>
Can you motivate why you want a function rather than a variable
for the counter control? For example, a useful feature of a
variable would be to bind it.
My basic feeling is that if we need a function rather than variable,
we must need the function for a reason. What is the function providing
that is worth the added descriptive overhead and loss of (binding)
flexibility but that is not stated in the writeup?
∂16-Mar-89 0807 CL-Cleanup-mailer Re: Issue: BREAK-ON-WARNINGS-OBSOLETE (Version 1)
Received: from multimax.encore.com by SAIL.Stanford.EDU with TCP; 16 Mar 89 08:06:57 PST
Received: from mist.encore.COM by multimax.encore.com with SMTP (5.61/25-eef)
id AA02088; Thu, 16 Mar 89 11:04:37 -0500
Received: from localhost by mist. (4.0/SMI-4.0)
id AA07042; Thu, 16 Mar 89 10:41:17 EST
Message-Id: <8903161541.AA07042@mist.>
To: CL-CLEANUP@Sail.stanford.edu
Subject: Re: Issue: BREAK-ON-WARNINGS-OBSOLETE (Version 1)
In-Reply-To: Your message of 15 Mar 89 17:16:00 -0800.
<890315-171714-1269@Xerox>
Date: Thu, 16 Mar 89 10:41:15 EST
From: Dan L. Pierson <pierson@mist.encore.com>
Sorry for the late reply on this.
The only problem with this proposal is that *BREAK-ON-SIGNALS* seems
to implicitly depend on either:
1. Having all condition types you want to control in one inheritance
tree.
2. Or SUBTYPEP supporting MEMBER type specifiers.
For example, suppose you create a new subtype of CONDITION, disjoint
from WARNING, called FROB, that does not break by default. Now
suppose you want to break on both WARNING and FROB, but not on another
disjoint subtype of CONDITION, say BLAT. The only way I can see to do
this would be:
(SETQ *BREAK-ON-SIGNALS* '(MEMBER WARNING FROB))
But this would presumably fail to work in an implementation that
compilied minimally with SUBTYPEP-TOO-VAGUE.
Of course, *BREAK-ON-WARNINGS* doesn't solve this problem, it just
dodges the one occurance of it that involves standard condition types.
∂16-Mar-89 0827 CL-Cleanup-mailer Re: Issue: BREAK-ON-WARNINGS-OBSOLETE (Version 1)
Received: from multimax.encore.com by SAIL.Stanford.EDU with TCP; 16 Mar 89 08:26:55 PST
Received: from mist.encore.COM by multimax.encore.com with SMTP (5.61/25-eef)
id AA02401; Thu, 16 Mar 89 11:24:37 -0500
Received: from localhost by mist. (4.0/SMI-4.0)
id AA07142; Thu, 16 Mar 89 11:22:55 EST
Message-Id: <8903161622.AA07142@mist.>
Cc: CL-CLEANUP@Sail.stanford.edu
Subject: Re: Issue: BREAK-ON-WARNINGS-OBSOLETE (Version 1)
In-Reply-To: Your message of Thu, 16 Mar 89 10:41:15 -0500.
<8903161541.AA07042@mist.>
Date: Thu, 16 Mar 89 11:22:50 EST
From: Dan L. Pierson <pierson@mist.encore.com>
Oops, braino. The previous version of this message used MEMBER when I
meant OR. Here is a corrected version:
Sorry for the late reply on this.
The only problem with this proposal is that *BREAK-ON-SIGNALS* seems
to implicitly depend on either:
1. Having all condition types you want to control in one inheritance
tree, or
2. SUBTYPEP supporting OR type specifiers.
For example, suppose you create a new subtype of CONDITION, disjoint
from WARNING, called FROB, that does not break by default. Now
suppose you want to break on both WARNING and FROB, but not on another
disjoint subtype of CONDITION, say BLAT. The only way I can see to do
this would be:
(SETQ *BREAK-ON-SIGNALS* '(OR WARNING FROB))
But this would presumably fail to work in an implementation that
compilied minimally with SUBTYPEP-TOO-VAGUE.
Of course, *BREAK-ON-WARNINGS* doesn't solve this problem, it just
dodges the one occurance of it that involves standard condition types.
∂16-Mar-89 0831 CL-Cleanup-mailer Re: issue PROCLAIM-LEXICAL (Version 9)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 16 Mar 89 08:31:50 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 16 MAR 89 08:27:48 PST
Date: 16 Mar 89 08:27 PST
From: masinter.pa@Xerox.COM
Subject: Re: issue PROCLAIM-LEXICAL (Version 9)
In-reply-to: Jeff Dalton <jeff%aiai.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK>'s
message of Wed, 15 Mar 89 20:10:25 GMT
To: Jeff Dalton <jeff%aiai.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK>
cc: masinter.pa@Xerox.COM, cl-cleanup@sail.stanford.edu
Message-ID: <890316-082748-3893@Xerox>
Does anyone at least have a record of the amendments that were proposed at
the last meeting. In lieu of a new version, we are probably obligated to
put version 9, as amended, on the table.
∂16-Mar-89 0917 CL-Cleanup-mailer Issue LOOP-AND-DISCREPANCY, version 1
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 16 Mar 89 09:17:31 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 558503; Thu 16-Mar-89 12:15:07 EST
Date: Thu, 16 Mar 89 12:15 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue LOOP-AND-DISCREPANCY, version 1
To: Guy Steele <gls@Think.COM>
cc: cl-cleanup@sail.stanford.edu
In-Reply-To: <8903151850.AA02865@verdi.think.com>
Message-ID: <19890316171508.0.MOON@EUPHRATES.SCRC.Symbolics.COM>
I like LOOP-AND-DISCREPANCY:NO-REITERATION.
∂16-Mar-89 0932 CL-Cleanup-mailer Re: issue PROCLAIM-LEXICAL (Version 9)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 16 Mar 89 09:32:12 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 558521; Thu 16-Mar-89 12:29:32 EST
Date: Thu, 16 Mar 89 12:29 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: issue PROCLAIM-LEXICAL (Version 9)
To: masinter.pa@Xerox.COM
cc: Jeff Dalton <jeff%aiai.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK>, cl-cleanup@sail.stanford.edu
In-Reply-To: <890316-082748-3893@Xerox>
Message-ID: <19890316172923.2.MOON@EUPHRATES.SCRC.Symbolics.COM>
Line-fold: No
Date: 16 Mar 89 08:27 PST
From: masinter.pa@Xerox.COM
Does anyone at least have a record of the amendments that were proposed at
the last meeting. In lieu of a new version, we are probably obligated to
put version 9, as amended, on the table.
Maybe I shouldn't take this attitude, but I will anyway. I have brief
notes on the amendments that were proposed, but since I think all of them
were wrongheaded and braindamaged, I'm not going to help anyone remember
them. Only one of the amendments was actually voted on, so we're certainly
free to forget the other two.
∂16-Mar-89 1044 CL-Cleanup-mailer Re: issue PROCLAIM-LEXICAL (Version 9)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 16 Mar 89 10:44:44 PST
Received: from Semillon.ms by ArpaGateway.ms ; 16 MAR 89 10:26:03 PST
Date: 16 Mar 89 10:02 PST
From: masinter.pa@Xerox.COM
Subject: Re: issue PROCLAIM-LEXICAL (Version 9)
In-reply-to: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>'s message
of Thu, 16 Mar 89 12:29 EST
To: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
cc: masinter.pa@Xerox.COM, Jeff Dalton
<jeff%aiai.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK>, cl-cleanup@sail.stanford.edu
Message-ID: <890316-102603-4543@Xerox>
What I meant to ask was: what amendments actually passed? If none, then we
can just bring up version 9 again. I think we can certainly ignore
amendments that were were voted on and failed or did not come far enough to
get to a vote.
∂16-Mar-89 1115 CL-Cleanup-mailer Issue: GENSYM-NAME-STICKINESS, version 2
Received: from Think.COM by SAIL.Stanford.EDU with TCP; 16 Mar 89 11:15:10 PST
Received: from fafnir.think.com by Think.COM; Thu, 16 Mar 89 13:52:43 EST
Return-Path: <gls@Think.COM>
Received: from verdi.think.com by fafnir.think.com; Thu, 16 Mar 89 13:53:38 EST
Received: by verdi.think.com; Thu, 16 Mar 89 13:50:26 EST
Date: Thu, 16 Mar 89 13:50:26 EST
From: Guy Steele <gls@Think.COM>
Message-Id: <8903161850.AA04888@verdi.think.com>
To: KMP@stony-brook.scrc.symbolics.com
Cc: GLS@Think.COM, CL-Cleanup@sail.stanford.edu
In-Reply-To: Kent M Pitman's message of Thu, 16 Mar 89 09:44 EST <890316094401.9.KMP@BOBOLINK.SCRC.Symbolics.COM>
Subject: Issue: GENSYM-NAME-STICKINESS, version 2
Date: Thu, 16 Mar 89 09:44 EST
From: Kent M Pitman <KMP@stony-brook.scrc.symbolics.com>
Can you motivate why you want a function rather than a variable
for the counter control? For example, a useful feature of a
variable would be to bind it.
My basic feeling is that if we need a function rather than variable,
we must need the function for a reason. What is the function providing
that is worth the added descriptive overhead and loss of (binding)
flexibility but that is not stated in the writeup?
So that at the time the counter is changed I can convert it to
packed decimal on a VAX and use string instructions.
Seriously, I had in mind doing error-checking at counter-setting time
and thus avoiding questions of what happens when if you supply a bogus
counter value.
But if that is not worth it, then I will settle for a variable.
--Guy
∂16-Mar-89 1143 CL-Cleanup-mailer Re: DRAFT Issue: CONDITION-RESTARTS (Version 1)
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 16 Mar 89 11:42:54 PST
Received: from defun.utah.edu by cs.utah.edu (5.61/utah-2.1-cs)
id AA02340; Thu, 16 Mar 89 12:39:36 -0700
Received: by defun.utah.edu (5.61/utah-2.0-leaf)
id AA05919; Thu, 16 Mar 89 12:39:34 -0700
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8903161939.AA05919@defun.utah.edu>
Date: Thu, 16 Mar 89 12:39:32 MST
Subject: Re: DRAFT Issue: CONDITION-RESTARTS (Version 1)
To: masinter.pa@Xerox.COM
Cc: cl-cleanup@SAIL.Stanford.EDU
In-Reply-To: masinter.pa@Xerox.COM, 16 Mar 89 10:24 PST
This issue impacts the cl-compiler issue COMPILER-DIAGNOSTICS. The
current proposal we have on that issue requires COMPILE-FILE to establish
a condition handler that resignals conditions. Obviously we have a
problem if resignalling is forbidden.
-Sandra
-------
∂16-Mar-89 1234 CL-Cleanup-mailer Re: Issue: BREAK-ON-WARNINGS-OBSOLETE (Version 1)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 16 Mar 89 12:34:03 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 558776; Thu 16-Mar-89 15:30:56 EST
Date: Thu, 16 Mar 89 15:30 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: Issue: BREAK-ON-WARNINGS-OBSOLETE (Version 1)
To: Dan L. Pierson <pierson@mist.encore.com>
cc: CL-CLEANUP@Sail.stanford.edu
In-Reply-To: <8903161622.AA07142@mist.>
Message-ID: <19890316203057.4.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Thu, 16 Mar 89 11:22:50 EST
From: Dan L. Pierson <pierson@mist.encore.com>
Oops, braino. The previous version of this message used MEMBER when I
meant OR. Here is a corrected version:
Sorry for the late reply on this.
The only problem with this proposal is that *BREAK-ON-SIGNALS* seems
to implicitly depend on either:
1. Having all condition types you want to control in one inheritance
tree, or
2. SUBTYPEP supporting OR type specifiers.
For example, suppose you create a new subtype of CONDITION, disjoint
from WARNING, called FROB, that does not break by default. Now
suppose you want to break on both WARNING and FROB, but not on another
disjoint subtype of CONDITION, say BLAT. The only way I can see to do
this would be:
(SETQ *BREAK-ON-SIGNALS* '(OR WARNING FROB))
But this would presumably fail to work in an implementation that
compilied minimally with SUBTYPEP-TOO-VAGUE.
I don't believe this is a real problem, because the signaller has a
condition object in its hand, so it would be calling TYPEP, not SUBTYPEP.
TYPEP has no problems working with OR.
In fact SUBTYPEP has no problems working with OR as the second argument,
so you have also pointed out a bug in SUBTYPEP-TOO-VAGUE; it should not
allow SUBTYPEP to fail when just the second argument involves OR. I think
this has been pointed out before.
∂16-Mar-89 1252 CL-Cleanup-mailer DEFAULT-CASE
Received: from ucbarpa.Berkeley.EDU by SAIL.Stanford.EDU with TCP; 16 Mar 89 12:52:43 PST
Received: from franz.UUCP by ucbarpa.Berkeley.EDU (5.61/1.33)
id AA18242; Thu, 16 Mar 89 12:24:16 -0800
Received: from frisky by franz (3.2/3.14)
id AA21310; Thu, 16 Mar 89 12:23:04 PST
Received: by frisky (3.2/3.14)
id AA08568; Thu, 16 Mar 89 12:21:59 PST
From: franz!frisky!jkf@ucbarpa.Berkeley.EDU (John Foderaro)
Return-Path: <frisky!jkf>
Message-Id: <8903162021.AA08568@frisky>
To: franz!sail.stanford.edu!CL-Cleanup
Subject: DEFAULT-CASE
Date: Thu, 16 Mar 89 12:21:57 PST
I brought up the issue of case-sensitive programming a few weeks
ago and there was no negative mail. My message was part of the
discussion on the READ-CASE-SENSITIVITY issue but in thinking it over
I believe that it makes more sense to look at what is needed to make
Common Lisp more useful in case-sensitive environments as two
separate things: 1. allow to the reader to be case-sensitive, and
2. make the names be lower-case by default. Item 1 is already being
worked on, here is item 2:
john foderaro
franz inc.
jkf%franz.uucp@berkeley.edu
Issue: DEFAULT-CASE
Forum: Cleanup
References: CLtL p 334 ff: What the Read Function Accepts;
especially p 337.
Issue: READ-CASE-SENSITIVITY
Category: CHANGE
Edit History: 16-Mar-89, Version 1 by jkf
Problem Description:
In most programming/operating-system environments where the case
of names of functions, programs, identifiers, and files *does*
matter, the case of most characters used for such purposes
is lower case. One example of such an environment is the Unix
operating system.
The resolution of the READ-CASE-SENSITIVITY will permit
one to write case-sensitive Lisp code however since the
the case of characters in the print names of all standard
functions and symbols is upper, this will make using
the Lisp in a case-sensitive mode difficult.
Proposal (DEFAULT-CASE:LOWER)
The case of all characters in the names of standard
functions, symbols, and packages is lower.
Rationale:
People running in a case-insensitive mode shouldn't care
which case is the default case.
People running in a case-sensitive mode care very much
which case is default, and for most of these people
lower case is preferred.
Furthermore there are a large number of users
of Lisp in case-sensitive environments and it is important
that the desires of these users be met.
Current Practice:
Franz Inc's Allegro Common Lisp supports a case-sensitive
reader with either a upper-case default for names
or a lower-case default. A number of people use the
case-sensitive feature with a lower-case default. I don't
know anyone that uses the lisp in a case-sensitive mode
with an upper-case default.
Cost to Implementors:
In case-insensitive mode, the cost to make characters downcase
rather than upcase should be small.
The cost of locating and fixing all of the places where
the default case of symbol names actually matters will be moderate
(I suspect that the older the Lisp the more numerous
the instances of dependency on the case of the names).
Cost to Users:
Again, the cost of locating and fixing all of the places where
the default case of symbol names actually matters will be moderate.
As an example, to find and fix all of the places in the PCL
source (~15000 lines) that depend on the default case took
me 15 minutes.
Cost of Non-Adoption:
Using Lisp in case-sensitive environments will continue to be
awkward.
It will continue to be hard for Lisp to interact
with programs written in case-sensitive languages (such as C).
The use of case sensitivity as a tool for writing programs
will continue to be unavailable to Lisp programmers.
Vendors will invent their own methods of adding case-sensitivity,
each in their own different way.
Benefits:
See 'Cost of Non-Adoption'.
Aesthetics:
Most Lisp books (including CLtL) put Lisp code in lower case.
I believe that most people prefer to read text written in lower case.
Discussion:
The best solution would be for there to be a way to make the
reader case-sensitive (i.e. a resolution to the READ-CASE-SENSITIVITY
issue) and for DEFAULT-CASE:LOWER to pass. If for some
reason the READ-CASE-SENSITIVITY should not be resolved in
a manner that results in a case-sensitive reader option, it would
still be good to pass DEFAULT-CASE:LOWER since that would
bring Common Lisp one giant step closer to supporting the
case-sensitive environment.
-------------------------------
∂16-Mar-89 1318 CL-Cleanup-mailer Issue: REMF-DESTRUCTION-UNSPECIFIED (Version 5)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 16 Mar 89 13:18:12 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 558836; Thu 16-Mar-89 16:11:38 EST
Date: Thu, 16 Mar 89 16:11 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: REMF-DESTRUCTION-UNSPECIFIED (Version 5)
To: Barry Margolin <barmar@FAFNIR.THINK.COM>
cc: masinter.pa@xerox.com, kmp@symbolics.com, cl-cleanup@sail.stanford.edu
In-Reply-To: <19890315185842.5.BARMAR@OCCAM.THINK.COM>
Message-ID: <19890316211129.6.MOON@EUPHRATES.SCRC.Symbolics.COM>
Line-fold: No
I don't have the mail message you referred to ("I suggest that the text
Amemdment I from my 14 February mail be used verbatim as the proposal.").
However, I like the way you dealt with NCONC in version 5, I don't
see any need for a separate proposal.
Generally this looks okay. I thought you were going to remove this:
(NSUBSTITUTE new-object old-object sequence ...)
(NSUBSTITUTE-IF new-object test sequence ...)
when sequence is a list, is permitted to SETF any part, CAR or
CDR, of the top-level list structure in that sequence.
when sequence is an array is permitted to SETF the contents of
any cell in that array which must be replaced by NEW-OBJECT.
since in fact there is no need to give NSUBSTITUTE the freedom
to modify anything more than what it is required to modify. I
still think it should be removed, just as NSUBST was removed.
∂16-Mar-89 1338 CL-Cleanup-mailer Issue: ENVIRONMENT-ENQUIRY (not submitted)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 16 Mar 89 13:38:11 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 16 MAR 89 13:17:03 PST
Date: 16 Mar 89 13:16 PST
From: masinter.pa@Xerox.COM
Subject: Issue: ENVIRONMENT-ENQUIRY (not submitted)
To: cl-cleanup@sail.stanford.edu
Message-ID: <890316-131703-5387@Xerox>
I had this on my status list:
* ENVIRONMENT-ENQUIRY
Synopsis: "The environment inquiry functions (pp447-448) don't return a
value in consistent format across implementations. This makes
them virtually useless. I would like to constrain the values
enough so that implementors knew what to provide as return
values, and provide some examples of intended uses."
Status: need volunteer to submit
I don't have much to say on this issue and cannot find message from which I
excerpted the quote. Who is the "I" here? Do you want to submit a proposal?
∂16-Mar-89 1338 CL-Cleanup-mailer Re: Issue EQUALP-GENERIC
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 16 Mar 89 13:38:24 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 16 MAR 89 13:23:03 PST
Date: 16 Mar 89 13:22 PST
From: masinter.pa@Xerox.COM
Subject: Re: Issue EQUALP-GENERIC
In-reply-to: Kim A. Barrett <IIM@ECLA.USC.EDU>'s message of Thu, 9 Mar 89
23:11:34 PST
To: Kim A. Barrett <IIM@ECLA.USC.EDU>
cc: Moon@SCRC-STONY-BROOK.ARPA, cl-cleanup@SAIL.STANFORD.EDU
Message-ID: <890316-132303-5408@Xerox>
I didn't think this was ready for release. Will there be a new version very soon?
∂16-Mar-89 1440 CL-Cleanup-mailer Re: issue PROCLAIM-LEXICAL (Version 9)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 16 Mar 89 14:40:07 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 558955; Thu 16-Mar-89 17:36:38 EST
Date: Thu, 16 Mar 89 17:36 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: issue PROCLAIM-LEXICAL (Version 9)
To: masinter.pa@Xerox.COM
cc: Jeff Dalton <jeff%aiai.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK>, cl-cleanup@sail.stanford.edu
In-Reply-To: <890316-102603-4543@Xerox>
Message-ID: <19890316223630.5.MOON@EUPHRATES.SCRC.Symbolics.COM>
Line-fold: No
Date: 16 Mar 89 10:02 PST
From: masinter.pa@Xerox.COM
What I meant to ask was: what amendments actually passed?
One amendment actually passed, but I'm still going to be a jerk and not
tell you what it was. If someone wants to propose the same amendment
again, I don't think that will waste very much time.
∂16-Mar-89 1518 CL-Cleanup-mailer DEFAULT-CASE
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 16 Mar 89 15:18:13 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 559010; Thu 16-Mar-89 18:15:06 EST
Date: Thu, 16 Mar 89 18:15 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: DEFAULT-CASE
To: John Foderaro <franz!frisky!jkf@ucbarpa.Berkeley.EDU>
cc: CL-Cleanup@sail.stanford.edu
In-Reply-To: <8903162021.AA08568@frisky>
Message-ID: <19890316231500.7.MOON@EUPHRATES.SCRC.Symbolics.COM>
Proposal (DEFAULT-CASE:LOWER)
The case of all characters in the names of standard
functions, symbols, and packages is lower.
You're proposing a huge incompatible change that is bound to
get you into a religious war that can't do anyone any good.
I claim that this proposal addresses the internal representation
of programs but all you care about is the external representation.
I also claim that the choice of case in internal representation
is arbitrary and need not prejudice the external representation
at all.
If you believe what I just said, you would propose that the reader get
an option to flip case instead of up-casing when converting from
external representation to internal representation, and would propose
another value for *print-case* that does the inverse transformation.
This would be compatible with everybody, would make everybody happy
except for those who might insist that one internal representation
is better than the other, and hopefully would avoid spending a lot
of time on discussion. What do you think?
∂16-Mar-89 1555 CL-Cleanup-mailer Issue: REMF-DESTRUCTION-UNSPECIFIED (Version 5)
Received: from Think.COM by SAIL.Stanford.EDU with TCP; 16 Mar 89 15:54:23 PST
Return-Path: <barmar@Think.COM>
Received: from OCCAM.THINK.COM by Think.COM; Thu, 16 Mar 89 17:24:17 EST
Date: Thu, 16 Mar 89 17:22 EST
From: Barry Margolin <barmar@Think.COM>
Subject: Issue: REMF-DESTRUCTION-UNSPECIFIED (Version 5)
To: David A. Moon <Moon@stony-brook.scrc.symbolics.com>
Cc: masinter.pa@xerox.com, kmp@symbolics.com, cl-cleanup@sail.stanford.edu
In-Reply-To: <19890316211129.6.MOON@EUPHRATES.SCRC.Symbolics.COM>
Message-Id: <19890316222229.3.BARMAR@OCCAM.THINK.COM>
Date: Thu, 16 Mar 89 16:11 EST
From: David A. Moon <Moon@stony-brook.scrc.symbolics.com>
I don't have the mail message you referred to ("I suggest that the text
Amemdment I from my 14 February mail be used verbatim as the proposal.").
However, I like the way you dealt with NCONC in version 5, I don't
see any need for a separate proposal.
Generally this looks okay. I thought you were going to remove this:
(NSUBSTITUTE new-object old-object sequence ...)
(NSUBSTITUTE-IF new-object test sequence ...)
when sequence is a list, is permitted to SETF any part, CAR or
CDR, of the top-level list structure in that sequence.
when sequence is an array is permitted to SETF the contents of
any cell in that array which must be replaced by NEW-OBJECT.
since in fact there is no need to give NSUBSTITUTE the freedom
to modify anything more than what it is required to modify. I
still think it should be removed, just as NSUBST was removed.
I think I remember my reason (it's been a month since I wrote the
amendment). I removed NSUBST because CLtL was already very specific
about what it does. CLtL's description of NSUBSTITUTE isn't very
specific; removing it from the proposal would just leave it implicitly
vague instead of making it explicitly vague, and I'd prefer to be
explicit.
I would support a version that makes NSUBSTITUTE* be explicitly
specific. I see no reason not to require it to use SETF of CAR or AREF,
as appropriate. Unless someone is working on CAR-coding, I don't think
it precludes any known optimizations.
barmar
∂16-Mar-89 1605 CL-Cleanup-mailer Issue: REMF-DESTRUCTION-UNSPECIFIED (Version 5)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 16 Mar 89 16:05:44 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 559069; Thu 16-Mar-89 19:02:17 EST
Date: Thu, 16 Mar 89 19:02 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: REMF-DESTRUCTION-UNSPECIFIED (Version 5)
To: Barry Margolin <barmar@Think.COM>
cc: masinter.pa@xerox.com, kmp@symbolics.com, cl-cleanup@sail.stanford.edu
In-Reply-To: <19890316222229.3.BARMAR@OCCAM.THINK.COM>
Message-ID: <19890317000217.3.MOON@EUPHRATES.SCRC.Symbolics.COM>
Line-fold: No
Date: Thu, 16 Mar 89 17:22 EST
From: Barry Margolin <barmar@Think.COM>
Date: Thu, 16 Mar 89 16:11 EST
From: David A. Moon <Moon@stony-brook.scrc.symbolics.com>
I don't have the mail message you referred to ("I suggest that the text
Amemdment I from my 14 February mail be used verbatim as the proposal.").
However, I like the way you dealt with NCONC in version 5, I don't
see any need for a separate proposal.
Generally this looks okay. I thought you were going to remove this:
(NSUBSTITUTE new-object old-object sequence ...)
(NSUBSTITUTE-IF new-object test sequence ...)
when sequence is a list, is permitted to SETF any part, CAR or
CDR, of the top-level list structure in that sequence.
when sequence is an array is permitted to SETF the contents of
any cell in that array which must be replaced by NEW-OBJECT.
since in fact there is no need to give NSUBSTITUTE the freedom
to modify anything more than what it is required to modify. I
still think it should be removed, just as NSUBST was removed.
I think I remember my reason (it's been a month since I wrote the
amendment). I removed NSUBST because CLtL was already very specific
about what it does. CLtL's description of NSUBSTITUTE isn't very
specific; removing it from the proposal would just leave it implicitly
vague instead of making it explicitly vague, and I'd prefer to be
explicit.
I see.
I would support a version that makes NSUBSTITUTE* be explicitly
specific. I see no reason not to require it to use SETF of CAR or AREF,
as appropriate. Unless someone is working on CAR-coding, I don't think
it precludes any known optimizations.
I'd support that too. In other words, describe NSUBSTITUTE with language
similar to the description of NSUBST.
∂16-Mar-89 1802 CL-Cleanup-mailer Issue: TYPE-OF-UNDERCONSTRAINED, v.5
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 16 Mar 89 18:02:00 PST
Received: from Semillon.ms by ArpaGateway.ms ; 16 MAR 89 17:54:51 PST
Date: 16 Mar 89 17:40 PST
From: masinter.pa@Xerox.COM
To: cl-cleanup@sail.stanford.edu
Subject: Issue: TYPE-OF-UNDERCONSTRAINED, v.5
Message-ID: <890316-175451-6328@Xerox>
I think Guy missed a couple of the amendments that passed
at the last meeting. This is what I started to send out
to X3J13, but since I've tried to "patch" the wording a bit
since it seems that some of the constraints put on TYPE-OF
by this proposal are overlapping, I thought I would send
it to cl-cleanup first. (Since this was raised at the last
meeting, there's not a problem about the 'two-week' rule,
I think.)
Version 3 of this proposal was raised at the January 1989
X3J13, and passed with three amendments:
a) add RANDOM-STATE to the list of types
b) add the requirement that TYPE-OF is a subtype of CLASS-OF
c) change the relation to CLOS to say
"for all objects
for which CLASS-OF returns a class with a proper name, TYPE-OF returns
that proper name."
It was noted that SHORT-FLOAT, LONG-FLOAT and RATIONAL were
omitted inadvertently. We would like to ask that the proposal
be reconsidered so that these types could also be included.
This version includes those amendments, and also
adds SHORT-FLOAT, LONG-FLOAT, and RATIONAL
to the list of types in part (a) of the proposal.
!
Forum: Cleanup
Issue: TYPE-OF-UNDERCONSTRAINED
References: TYPE-OF (CLtL)
88-002R (Class-of)
88-005, p 43f, Condition system types
Related issues: SUBTYPEP-TOO-VAGUE
DATA-TYPE-HIERARCHY-UNDERSPECIFIED
FUNCTION-TYPE
ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS
COERCE-INCOMPLETE
Category: CLARIFICATION/CHANGE
Edit history: Version 1, 1-Dec-88, Masinter
Version 2, 9-Dec-88, Masinter
Version 3, 12-Dec-88, Masinter (fix "egregious bug")
Version 4, 3-14-89 Steele
Version 5, 16-Mar-89, Masinter (add other amendments)
Problem description:
The specification of TYPE-OF in CLtL is so weak as to leave it
nearly useless, if any implementor actually took the specification
seriously.In particular, there are almost no constraints on the
value that TYPE-OF might return for any of the built in
types. The only constraint placed is that for objects created by the
constructor function of DEFSTRUCT, the result of TYPE-OF is the name of the
defstruct.
This means that implementations could return T for all other objects.
Proposal (TYPE-OF-UNDERCONSTRAINED:ADD-CONSTRAINTS):
Specify that the result of TYPE-OF satisfies the following:
(a) For any object for which (typep object built-in-type) is true when
built-in-type is one of
INTEGER, RATIO, FLOAT, SINGLE-FLOAT, DOUBLE-FLOAT, COMPLEX, NUMBER,
SYMBOL,
STRING, VECTOR, ARRAY, RANDOM-STATE,
CONS,
STREAM, PACKAGE, CHARACTER, FUNCTION, READTABLE, HASH-TABLE, PATHNAME,
CONDITION, RESTART,
RATIONAL, SHORT-FLOAT, LONG-FLOAT
the result of TYPE-OF will be a type specifier for which
(subtypep (type-of object) built-in-type) returns T T, i.e., either the
build-in-type or a subtype of it (a subtype that the
implementation's SUBTYPEP can recognize.)
(b) For all objects, (TYPEP object (TYPE-OF object)) will be true.
(this implies that it will not be NIL, since no
object is of type NIL.)
(c) will not be a MEMBER type specifier, or T.
The type returned by TYPE-OF is always a subtype of the class
returned by CLASS-OF.
For all objects for which CLASS-OF returns a class with a proper name,
TYPE-OF returns that proper name.
In particular, for objects created by the "constructor" function
of a structure defined with DEFSTRUCT without a :TYPE option,
TYPE-OF will return the structure name.
For all objects for which (CLASS-NAME (CLASS-OF object)) is NIL),
the result of TYPE-OF will return the class object itself.
(The CLOS specification has already specified that class objects are
acceptable wherever type specifiers are, and in particular, as input to
SUBTYPEP and TYPEP.)
This proposal is intended to be consistent with 88-002R,
and not to conflict with any of the definitions in that document.
Examples:
It is legal for (TYPE-OF "abc") to return (SIMPLE-STRING 3), or just
STRING. It is legal for (TYPE-OF 112312) to return SI:MEDIUM-SIZE-FIXNUM,
as long as (SUBTYPEP 'SI:MEDIUM-SIZE-FIXNUM 'INTEGER).
Given:
(defvar *foo* (make-array 5 :element-type t))
(class-name (class-of *foo*)) => SIMPLE-VECTOR
It is legal for
(type-of *foo*) => (SIMPLE-VECTOR 5)
Rationale:
The original specification for "TYPE-OF" was written to allow
implementation freedom, but the wording is in fact more vague than was
intended.
Current practice:
Most Common Lisp implementations seem to implement the proposal, at least
for the types we've tried them on.
Cost to Implementors:
Even if there are implementations that do not currently implement the
proposal, the required changes for them are likely to be minimal.
Cost to Users:
Apparently none.
Cost of non-adoption:
TYPE-OF would remain potentially inconsistent.
Performance impact:
Likely none.
Benefits:
Bring the specification of TYPE-OF in like with its common
implementation, while requiring it to be generally useful.
Esthetics:
Little effect.
Discussion:
Originally, TYPE-OF was concieved as being useful for information display.
CLOS specified CLASS-OF far more precisely, in that it must return exactly
the class of an object. Unless TYPE-OF is removed from the language, it
seems reasonable to require it to be at least as precise as CLASS-OF.
The accepted CLOS specification does not define CLASS-OF
in terms of TYPE-OF, but an earlier draft did.
This proposal presumes the (passed) proposals
DATA-TYPES-HIERARCHY-UNDERSPECIFIED:DISJOINT, FUNCTION-TYPE, and
accomodates the Condition System (version 18) and CLOS.
If ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS does not pass,
and this proposal does pass, it may be that the only way an
implementation can satisfy (TYPEP array (TYPE-OF array))
would be to have (TYPE-OF array) return VECTOR or ARRAY
as appropriate, i.e., with no element type qualification.
It is possible to constrain TYPE-OF further, e.g., to eliminate
the possibility that it might return a non-portable
implementation-specific value. For example,
(TYPE-OF 112312) should not return SI:MEDIUM-SIZE-FIXNUM, but rather some
thing like (SIGNED-BYTE 17) [if that's what SI:MEDIUM-SIZE-FIXNUM means.]
We would like to make this as an implementation recommendation,
however, rather than as a constraint, at this point.
----- End Forwarded Messages -----
∂16-Mar-89 2116 CL-Cleanup-mailer Re: Issue: EXPT-ZERO-ZERO (Version 1)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 16 Mar 89 21:16:33 PST
Received: from Semillon.ms by ArpaGateway.ms ; 16 MAR 89 21:10:42 PST
Date: 16 Mar 89 21:10 PST
From: masinter.pa@Xerox.COM
Subject: Re: Issue: EXPT-ZERO-ZERO (Version 1)
To: KMP@symbolics.com, CL-Cleanup@sail.stanford.edu,
Cyphers@jasper.scrc.symbolics.com
Message-ID: <890316-211042-6708@Xerox>
Kent, do you want to proceed with this one? I don't think it is necessary
or even a good idea. What do other programming languages do?
If you do, I think we should leave (EXPT 0 0) = 1 and (EXPT 0.0 0) = 1 and
only deal with (EXPT 0.0 0.0) and (EXPT 0 0.0).
Doesn't this fit into the ERRORS-IN-NUMBERS-CHAPTER spectrum?
∂16-Mar-89 2212 CL-Cleanup-mailer Issue: FIXNUM-NON-PORTABLE, v.5
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 16 Mar 89 22:11:59 PST
Received: from Semillon.ms by ArpaGateway.ms ; 16 MAR 89 22:09:33 PST
Date: 16 Mar 89 21:51 PST
From: masinter.pa@Xerox.COM
to: cl-cleanup@sail.stanford.edu
Subject: Issue: FIXNUM-NON-PORTABLE, v.5
line-fold: NO
Message-ID: <890316-220933-6804@Xerox>
This is my rewrite to capture the 'intent' of the amendment
at the January X3J13. I say 'intent' because the relation
between MOST-POSITIVE-FIXNUM (which is an inclusive bound)
and ARRAY-DIMENSION-LIMIT (which is an exclusive bound) is not
> but rather (>= MOST-POSITIVE-FIXNUM (1- ARRAY-DIMENSION-LIMIT)).
A minor nit. I wonder if we need to bring copies of the issues
that were passed at the last meeting for the 'approval of
the minutes' part.
!
Status: Passed Jan 89 X3J13, as amended
Issue: FIXNUM-NON-PORTABLE
References: CLtL p. 14, 34, 43, 231
Category: CHANGE, CLARIFICATION
Edit History: Version 1, 11-Jul-88, Sandra Loosemore
Version 2, 15-Sep-88, Masinter
Version 3, 23-Sep-88, Masinter
Version 4, 7-Dec-88, Masinter (two proposals)
Version 5, 16-Mar-89, Masinter (incorporate amendments)
Problem Description:
Implementations of Common Lisp are required to support two disjoint
subsets of integers, fixnums and bignums, with the promise that
fixnums have a more efficient representation. However, nothing is
guaranteed about the range of integers which are fixnums: "Exactly
which integers are fixnums is implementation-dependent; typically they
will be those integers in the range -2**n to 2**n - 1, inclusive, for
some n not less than 15."
There are few uses of the fixnum type that are portable, given the
current definition. In particular, many programmers use FIXNUM type
declarations where they really mean "small integer".
While most Common Lisp implementations have a FIXNUM range
which is a subset of integers represeted and operated on most
efficiently, many also have several other subranges. The
partitioning of INTEGER into BIGNUM and FIXNUM is merely
confusing in these implementations, and not useful.
CLtL p14 and p34 disagree about BIGNUM. One says that
FIXNUM and BIGNUM are an exhaustive partition of the
integer space, the other says they might not be!
Proposal: FIXNUM-NONPORTABLE:TIGHTEN-DEFINITION
(1) Change the description of the type FIXNUM to reflect that it is
required to be a supertype of (SIGNED-BYTE 16).
(2) Define BIGNUM to be exactly (AND INTEGER (NOT FIXNUM))
(3) require that MOST-POSITIVE-FIXNUM be large enough
to hold all array indices, i.e.,
(>= MOST-POSITIVE-FIXNUM (1- ARRAY-DIMENSION-LIMIT))
Example:
Consider an implementation with three numeric representations:
Fast (INTEGER -1024 1023)
Immediate 29 bits
Extended Multi-precision
Such an implementation would have to define
FIXNUM to be (OR Fast Immediate). BIGNUM
would then refer to multi-precision integers.
Rationale:
Many programmers already use FIXNUM to mean "small integer"; this
proposal makes this usage portable.
However, there is little portable use for the type BIGNUM, and it
is inconsistent with many current implementation techniques.
Removing it is an incompatible change for a weak reason.
Current Practice:
Xerox Common Lisp has 17-bit fixnums. Most other Common Lisp
implementations have fixnum ranges of 24 bits or larger. We know
of no implementation that currently violates the proposed minimum
size.
Several existing Common Lisp implementations have more than two
representations for integers, such that the FIXNUM/BIGNUM distinction
is confusing; they define BIGNUM to cover all of the larger number
types.
Cost to implementors:
Slight. All implementations we know of already define FIXNUMs to be at
least 16 bits.
Cost to users:
Slight.
Benefits:
The FIXNUM type specifier would have a portable interpretation.
The language would be less confusing.
Discussion:
There was little consensus on whether to leave BIGNUM in the language.
Earlier discussion of a related proposal contained several other more controversial
components (adding a constant MAX-INTEGER-LENGTH, allowing
MOST-POSITIVE-FIXNUM to be NIL as well as an integer.) This proposal
is an attempt to address the part that cleanup committee seemed to agree on.
It is possible that an implementation have a single representation for all
integers, and no way to identify any efficient range of integers. Those
implementations might need to set MOST-POSITIVE-FIXNUM
and MOST-NEGATIVE-FIXNUM to arbitrary values, consistent with
the requirement that (SIGNED-BYTE 16) is a subtype of FIXNUM.
Other alternatives considered (and not necessarily mutually exclusive
with this proposal):
remove the FIXNUM type specifier entirely, while leaving a way
to query what is the most efficient range of integers
leave the range of FIXNUMs unconstrained and introduce a
SMALL-INTEGER type with a fixed range (but no promises about
efficiency) .
It might be possible to specify the required performance behavior
of FIXNUMs more concretely, e.g., specify that the basic integer operations
use algorithms that are not proportional to the size of the data; it
should be just about as fast to add numbers in the middle of the fixnum
range as it is to add, say, 10 and 11. This might be a useful way to describe
the intent of the FIXNUM range, if not its specification.
∂16-Mar-89 2253 CL-Cleanup-mailer Re: DEFAULT-CASE
Received: from ucbarpa.Berkeley.EDU by SAIL.Stanford.EDU with TCP; 16 Mar 89 22:53:03 PST
Received: from franz.UUCP by ucbarpa.Berkeley.EDU (5.61/1.33)
id AA29249; Thu, 16 Mar 89 22:20:22 -0800
Received: from frisky by franz (3.2/3.14)
id AA22529; Thu, 16 Mar 89 21:39:21 PST
Received: by frisky (3.2/3.14)
id AA09727; Thu, 16 Mar 89 21:38:16 PST
From: franz!frisky!jkf@ucbarpa.Berkeley.EDU (John Foderaro)
Return-Path: <frisky!jkf>
Message-Id: <8903170538.AA09727@frisky>
To: David A. Moon <franz!ucbarpa!STONY-BROOK.SCRC.Symbolics.COM!Moon>
Cc: franz!sail.stanford.edu!CL-Cleanup
Subject: Re: DEFAULT-CASE
In-Reply-To: Your message of Thu, 16 Mar 89 18:15:00 EST.
<19890316231500.7.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Thu, 16 Mar 89 21:38:14 PST
I'm not trying to start a religious war. I'm not saying that
case-sensitive is better or worse than case-insensitive. I'm just
saying that there are large numbers of people who favor each position
and that Common Lisp should support both.
Regarding internal vrs external: The internal representation shows
through in a number of places. For example the functions symbol-name
and make-symbol let the user deal with the actual internal
representation of the names of symbols. The idea of having a
*print-case* value that inverts the case on output is interesting but
that would make things awkward: To make the symbol FooBar you
would have to (make-symbol "fOObAR"). Also examining the characters
of a print-name with aref would give confusing results.
>> I also claim that the choice of case in internal representation
>> is arbitrary and need not prejudice the external representation
>> at all.
For a case-insensitive Lisp I completely agree. For a case-sensitive
Lisp, as I've shown above, this just isn't true. Thus if the needs
of the case-sensitive Lisp are met, then the needs of both are met.
-john foderaro
[it might be interesting to explore the possiblity of explicitly
stating that the internal representation of print-names was undefined
with respect to case, and further providing two new functions: one
which took a string and converted it to the internal representation
just as the reader would do and the other which took a symbol-name
and converted it to a string just as the printer would do.
I suspect that this would lead to programs that worked on a few
Common Lisps but failed on others due to accidental reliance on the
actual case of the printnames. ]
∂16-Mar-89 2310 CL-Cleanup-mailer Re: Issue: IN-SYNTAX (Version 1)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 16 Mar 89 23:10:33 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 16 MAR 89 23:05:56 PST
Date: 16 Mar 89 23:05 PST
From: masinter.pa@Xerox.COM
Subject: Re: Issue: IN-SYNTAX (Version 1)
In-reply-to: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>'s message
of Fri, 21 Oct 88 14:01 EDT
To: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
cc: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <890316-230556-6907@Xerox>
The discussion of this Issue quickly evolved into a discussion of the
default environment for LOAD. I don't see much in the way of the discussion
of the issue itself except "far too narrowly focused."
Under the circumstances -- and given that I'm not that thrilled by adding
Yet Another Puppy that We Aren't Sure We Need -- can we drop this?
∂17-Mar-89 0009 CL-Cleanup-mailer Cleanup Issue Status List
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 17 Mar 89 00:09:24 PST
Received: from Semillon.ms by ArpaGateway.ms ; 16 MAR 89 23:57:10 PST
Date: 16 Mar 89 23:56 PST
From: masinter.pa@Xerox.COM
cc: masinter.pa@Xerox.COM
to: cl-cleanup@sail.stanford.edu
Subject: Cleanup Issue Status List
Message-ID: <890316-235710-7002@Xerox>
I'm out of steam and only in the middle of the alphabet. I'll try to slug
through M-Z tomorrow. I'm travelling or unavailable most of next week, and
so this has to get done now.
! ready for vote
+ passed
!+: passed, but up for reconsideration
- withdrawn, failed, etc.
* pending, passed but need version as amended, etc.
+ ADJUST-ARRAY-DISPLACEMENT
Version 4, 23-Nov-87
Status: passed, 1988
+ ADJUST-ARRAY-FILL-POINTER
Version 1, 15-MAR-88
Status: passed, 1988
! ADJUST-ARRAY-NOT-ADJUSTABLE
Synopsis: ADJUST-ARRAY on array made with :ADJUSTABLE NIL: "an error"?
Version 4, 11-Jan-89, Released 12-Jan-89
Status: Accepted with amendments Jan 89 X3J13
Comments: amendment had wording problem.
Version 8, 11-Mar-89, Released 15-Mar-89
Status: ready for vote
- ALIST-NIL
Version 4, 1-Oct-88
Status: Withdrawn, recommend editorial
- APPEND-ATOM
Synopsis: atom case of APPEND (left out of APPEND-DOTTED)
Version 1, 6-Dec-88, Released 12-Jan-89
Status: withdrawn 18-Jan-89 because APPEND-DOTTED withdrawn
- APPEND-DOTTED
14-JAN-88, Version 5
Status: Passed Nov 88 X3J13, reconsidered & withdrawn Jan 89 X3J13
+ APPLYHOOK-ENVIRONMENT
Synopsis: remove (useless) env argument to applyhook
Version 2, 10-Jan-89, Released 10-Jan-89
Status: Passed Jan-89 X3J13
+ AREF-1D
14-NOV-87, Version 7
Status: Passed, 1988?
+ ARGUMENTS-UNDERSPECIFIED
Synopsis: Clarify various ranges missing from CLtL
Version 4, 21-Sep-88, Released 4 Dec 88
Status: Passed Jan 89 X3J13
+ AREF-1D
Version 7, 14-NOV-87
Status: Passed, 1988?
+ ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS
Synopsis: What do array element-type declarations mean?
Version 9, 31-Oct-88, Released 5 Dec 88
Status: Passed Jan 89 X3J13
+ ASSOC-RASSOC-IF-KEY
Version 4, 23-NOV-87
Status: Passed, 1988?
- BACKQUOTE-COMMA-ATSIGN-DOT
Synopsis: `(... ,@x) vs `(... . ,x). Same, different, is error?
Version 1, 22-Dec-88, DRAFT released
Comments: proposals INTERCHANGABLE and DIVERGENT comments not in writeup
Status: Withdrawn, since APPEND-DOTTED withdrawn. Default is IS ERROR
! BREAK-ON-WARNINGS-OBSOLETE
Synopsis: deprecate *BREAK-ON-WARNINGS* because of *BREAK-ON-SIGNALS*
Version 1, 07-Mar-89, Released 15-Mar-89
Comment: leaves out a case
Status: ready for vote
! CLOS-CONDITIONS
Version 4, 10-Mar-89
Comments: define metaclass of conditions?
Status: pending
+ CLOSE-CONSTRUCTED-STREAMS
Synopsis: What does it mean to CLOSE a constructed stream?
Version 2, 12-Jan-89, Released 12-Jan-89
Status: Proposal ARGUMENT-STREAM-ONLY passed Jan 89 X3J13
!+ CLOSED-STREAM-OPERATIONS
Synopsis: What operations are legal on closed streams?
Version 5, 5-Dec-88, released 5-Dec-88
Status: amended at meeting
Version 7, 14-Feb-89
Status: Passed, as amended, Jan 89 X3J13
Comment: amendment bad; reconsider version 5?
amend 5 to say that INPUT-STREAM-P and OUTPUT-STREAM-P
are undefined on closed streams?
! COERCE-INCOMPLETE
Synopsis: Extend COERCE
Version 3, 7-Mar-89, Released 14-Mar-89
Status: ready for voting
+ COLON-NUMBER
Synopsis: :123 is an error
22-OCT-87, Version 1
Status: Passed, 1988?
+ COMPILER-WARNING-STREAM
Version 6, 5-JUN-87
Status: Passed, 1988?
+ COMPLEX-ATAN-BRANCH-CUT
Synopsis: tweak upper branch cut in ATAN formula
Version 1, 13-Dec-88, Released 10-Jan-89
Status: Passed Jan 89 X3J13
! CONDITION-RESTARTS
Synopsis: can't know whether restart is associated with signalling
Version 1, 18-Jan-89, released 16-Mar-89
Comment: (proposed amendments)
Status: vote w/amendments or new version
+ CONTAGION-ON-NUMERICAL-COMPARISONS
Version 1, 14-Sep-88, Released 6 Oct 88
Status: passed, Jan 89 X3J13
! COPY-SYMBOL-COPY-PLIST
Version 1, 10-Jan-89, released 16-Mar-89
Status: ready for vote
! COPY-SYMBOL-PRINT-NAME
Version 2, 15-Mar-89, released 16-Mar-89
Status: ready for vote
+ DATA-TYPES-HIERARCHY-UNDERSPECIFIED
4-SEP-88 Version 2
Status: Passed, 1988?
+ DECLARATION-SCOPE
Version 4, 15-Nov-88, Released 9-Dec-88
Status: NO-HOISTING passed Jan 89 X3J13
+ DECLARE-ARRAY-TYPE-ELEMENT-REFERENCES
Version 3, 13-Jan-89
Status: passed, Jan 89 X3J13
kc: amended?
+ DECLARE-FUNCTION-AMBIGUITY
Version 4, 5-Dec-88, Released 5-Dec-88
Status: passed, Jan 89 X3J13
+ DECLARE-TYPE-FREE
Version 10, 12-Jan-89
Status: proposal LEXICAL passed Jan 89 X3J13
+ DECLARE-MACROS
5-FEB-88, Version 3
Status: Passed, 1988?
- DECLARE-TYPE-USER-DEFINED
Synopsis: allow (declare ((signed-byte 8) x y z)) for all type specifiers?
Status: Withdrawn (never submitted)
+ DECODE-UNIVERSAL-TIME-DAYLIGHT
Version 2, 30-Sep-88, Released 6 Oct 88
Status: Passed, Jan 89 x3j13
- DEFINITION-DELETE
Synopsis: provide a way to get rid of structures, etc.
Status: not submitted
* DEFMACRO-LAMBDA-LIST
Version 1, 30-Jan-89
Status: *** NEED NEW VERSION ***
+ DEFPACKAGE
Version 7, 2-Nov-88, Released 5 Dec 88
Comment: clarify "at variance" in editorial work?
Status: Passed, Jan 89 X3J13
- DEFSTRUCT-ACCESS-FUNCTIONS-INLINE
Synopsis: defstruct accessors are proclaimed inline
Version 2, 7-Jan-89, released 10-Jan-89
Status: rejected, Jan 89 X3J13
+ DEFSTRUCT-CONSTRUCTOR-KEY-MIXTURE
Version 3, 8-Jan-89, Released 11-Jan-89
Status: Passed, Jan 89 X3J13
+ DEFSTRUCT-PRINT-FUNCTION-INHERITANCE
Version 3, 7 Dec 88, Released 12-Dec-88
Status: Passed, Jan 89 X3J13
+ DEFSTRUCT-REDEFINITION
Synopsis: what happens if you redefine a DEFSTRUCT?
Version 3, 6-Feb-89
Status: Passed (as amended) Jan 89 X3J13
+ DEFSTRUCT-SLOTS-CONSTRAINTS-NAME
Version 5, 12-Jan-89
Status: Passed, Jan 89 X3J13
+ DEFVAR-DOCUMENTATION
23-NOV-87, Version 2
Status: Passed, 1988?
+ DEFVAR-INIT-TIME
29-MAR-87, Version 2
Status: Passed, 1988?
+ DEFVAR-INITIALIZATION
Version 4 5-JUN-87
Status: Passed, 1988?
- DELETE-FILE-NONEXISTENT
Version 1, 5-Oct-88
Comments: should just signal different errors?
Status: withdrawn/tabled?
+ DESCRIBE-INTERACTIVE
Version 4, 15-Nov-88, Released 7-Dec-88
Synopsis: can DESCRIBE ask user a question?
Status: Proposal NO passed Jan 89 X3J13
! DESCRIBE-UNDERSPECIFIED
Version 1, 10-Mar-89, Released 16-Mar-89
Synopsis: making DESCRIBE generic was wrong; fix
status: ready for vote
!* DESTRUCTURING-BIND
Version 2, 25-Jan-89, Released 16-Mar-89
Synopsis: add DESTRUCTURING-BIND macro
Status: might need new version before vote
+ DISASSEMBLE-SIDE-EFFECT
Version 3 1/21/88
Status: Passed, 1988
+ DO-SYMBOLS-DUPLICATES
Version 3 23-NOV-87
Status: Passed, 1988?
+ DOTTED-MACRO-FORMS
Version 3, 15-Nov-88, Released 7-Dec-88
Status: passed, Jan 89 X3J13
+ DRIBBLE-TECHNIQUE
14-FEB-88, Version 2
Status: Passed, 1988?
! DYNAMIC-EXTENT
Version 3, 11-Jan-89, released 16-Mar-89
Comments: still some holes
Status: ready for vote?
- ELIMINATE-FORCED-CONSING
Synopsis: Add :RECYCLE or :MODIFY to some sequence fns,
Version 3, 31-Aug-88
Status: withdrawn
- ENVIRONMENT-ENQUIRY
Synopsis: "The environment inquiry functions (pp447-448) don't return a
value in consistent format across implementations. This makes
them virtually useless. I would like to constrain the values
enough so that implementors knew what to provide as return
values, and provide some examples of intended uses."
Status: no volunteer to submit
+ EQUAL-STRUCTURE
Version 6, 11-Jan-89, Released 12-Jan-89
Status: Passed with amendments
Version 7, 15-Mar-89
Status: Passed Jan 89 X3J13 as amended.
* EQUALP-GENERIC
Version 1, 28-Feb-89
Synopsis: make EQUALP generic function
Comments: Various problems being worked on
Status: ** NEED NEW VERSION ***
* ERROR-CHECKING-IN-NUMBERS-CHAPTER
Version 1, 6-Mar-89
Synopsis: define 'should signal', 'might signal' for number fns
Status: in progress, "endorse in principle"?
! ERROR-NOT-HANDLED
Version 1, 25-Sep-88, Released 6-Oct-88 and 14-Mar-89
Status: ready for vote
+ EVAL-OTHER
8-JUN-88, Version 2
Status: Passed, 1988?
! EXIT-EXTENT
Version 6, 8-Jan-89, distributed at Jan89 X3J13
Rereleased 16-Mar-89
Status: tabled Jan89; ready for vote
+ EXPT-RATIO
Version 3, 31-Oct-88, Released 7 Dec 88
Status: passed, Jan 89 X3J13
* EXPT-ZERO-ZERO
Synopsis: (EXPT 0.0 0.0) should be undefined
Version 1, 27-Feb-89
Status: need new version?
- FILE-LENGTH-PATHNAME
Synopsis: extend FILE-LENGTH to work on pathnames
Status: not submitted/ withdrawn
* FILE-WRITE-DATE-IF-NOT-EXISTS
Synopsis: What does FILE-WRITE-DATE do if no such file?
Version: no proposal
Status: => ERRORS-IN-FILE-SYSTEM-CHAPTER????
+ FIXNUM-NON-PORTABLE
Version 4, 7-Dec-88, Released 12-Dec-88
Status: Accepted with amendment
Version 5, 16-Mar-89, "as amended"
Comment: minor off-by-one in amendment
Status: voice approval for off-by-one?
+ FLET-DECLARATIONS
Version 2, 2 FEB 88
Status: Passed, 1988?
+ FLET-IMPLICIT-BLOCK
Version 6 5-JUN-87
Status: Passed, 1988?
- FOLLOW-SYNONYM-STREAM
Comment: lost in STREAM-ACCESS.
Status: Withdrawn?
+ FORMAT-ATSIGN-COLON
Version 4 5-JUN-87
Status: Passed, 1988?
+ FORMAT-COLON-UPARROW-SCOPE
Version 3, 5 FEB 88
Status: Passed, 1988?
+ FORMAT-COMMA-INTERVAL
Version 2, 15-JUN-87
Status: Passed, 1988?
+ FORMAT-E-EXPONENT-SIGN
Version 2, 2 Oct 88, Released 6 Oct 88
Status: Passed, Jan 89 X3J13
+ FORMAT-OP-C
11-JUN-87, Version 5
Status: Passed, 1988?
- FORMAT-NEGATIVE-PARAMETERS
Synopsis: What does FORMAT do when it gets negative numbers for count?
Version: No proposal
Comment: KMP will incorporate in the list-of-signals part of the signal
proposal?
Status: not submitted
* FORMAT-PLURALS
Synopsis: remove ~P, add ~:@[singular~;plural~]
Status: no proposal
+ FORMAT-PRETTY-PRINT
Version 7, 15 Dec 88, Released 7 Dec 88
Comments: passed, Jan 89 X3j13
- FORMAT-ROUNDING
Synopsis: specify that ~F rounds up
Version 1, 5-Oct-88
Status: withdrawn
* FUNCTION-ARGUMENT-LIST
Synopsis: want way to get argument list
Status: not submitted
+ FUNCTION-CALL-EVALUATION-ORDER
Version 1, 22-MAR-88
Status: Passed, 1988
! FUNCTION-COERCE-TIME
Synopsis: When does SYMBOL-FUNCTION happen in MAPCAR?
Version 2, 16-sep-88, Released 8-Oct-88
Re-released: 16-Mar-89
Status: vote?
+ FUNCTION-COMPOSITION
Synopsis: Add new functions
Version 5, 10-Feb-89
Status: Passed (as amended) Jan 89 X3J13?
Status: maybe this was passed as amendment to TEST-NOT-IF-NOT instead
but in either case, we have the content.
+ FUNCTION-DEFINITION
Version 3, 10-Feb-89
Status: Passed (as amended) Jan 89 X3J13
+ FUNCTION-TYPE
4-SEP-88, Version 12
Status: Passed, 1988
+ FUNCTION-TYPE-ARGUMENT-TYPE-SEMANTICS
Synopsis: Change semantics of argument types in function declarations
Version 3, 7-Dec-88, Released 12-Dec-88
Status: Passed, Jan 89 X3J13
+ FUNCTION-TYPE-KEY-NAME
Version 3, 13-FEB-88
Status: Passed, 1988
+ FUNCTION-TYPE-REST-LIST-ELEMENT
Version 5, 14-Nov-88, Released 8-Dec-88
Status: Passed, Jan 89 X3J13
- GCD-NO-ARGUMENTS
Synopsis: make (GCD) undefined
Status: not submitted
*! GENSYM-NAME-STICKINESS
Version 1, 14-Feb-89, Released 14-Mar-89
Synopsis: no side effects if optional arg supplied
Status: need new version
- GET-MACRO-CHARACTER-DISPATCHING
Synopsis: What does GET-MACRO-CHARACTER return for dispatching macros?
Status: not submitted
+ GET-MACRO-CHARACTER-READTABLE
Version 3, 11-Feb-89
Status: Passed (as amended) Jan 89 X3J13
+ GET-SETF-METHOD-ENVIRONMENT
Version 5 13-JUL-87
Status: Passed, 1988?
! HASH-TABLE-ACCESS
Synopsis: Add new accessors for hash-table properties
Version 1, 13-Sep-88 released 8-Oct-88
Version 2, 13 Oct 88, released 16-Mar-89
status: vote
- HASH-TABLE-GC
Synopsis: allow hash tables with GCable keys
Status: no proposal
+ HASH-TABLE-PACKAGE-GENERATORS
Version 7, 8-Dec-88, Released 9-Dec-88
Comments: The test-package-iterator example has the values
from the generator in the wrong order.
Status: passed, Jan 89 X3J13
* HASH-TABLE-PRINTED-REPRESENTATION
Version 2, 8-Jun-88
Comments: Use #S(ARRAY ...), #S(HASH-TABLE...), #S(PATHNAME...)?
Status: need new proposal
- HASH-TABLE-STABILITY
Version 1, 11-Nov-88, Released 12 Dec 88
Comments: superceded HASH-TABLE-KEY-MODIFICATION
Status: Rejected Jan 89 X3J13
+ HASH-TABLE-TESTS
Version 2, 8-Dec-88, Released 8 Dec 8 8
Status: passed Jan 89 X3J13
+ IEEE-ATAN-BRANCH-CUT
Version 2, 11-Jan-89, Released 11-Jan-89
Status: passed, Jan 89 X3J13
* IGNORE-VARIABLE
Synopsis: default (IGNORE IGNORE)
Version 1, 6-Feb-89
+ IMPORT-SETF-SYMBOL-PACKAGE
Version 5 ??-MAY-87
Status: Passed, 1988?
! IN-PACKAGE-FUNCTIONALITY
Version 4, 12-Dec-88, Released 12-Dec-88
Status: tabled
Version 8, 15-Mar-89, Released 15-Mar-89
Status: ready for vote
- IN-SYNTAX
Synopsis: like IN-PACKAGE but for readtables
Version 1, 21-Oct-88
Comments: important issue: default environment for LOAD
Status: can we withdraw?
- INPUT-STREAM-P-CLOSED
Synopsis: What do INPUT-STREAM-P and OUTPUT-STREAM-P do on closed streams?
Status: not submitted
- INPUT-STREAM-P-EXAMPLE
Synopsis: (input-stream-p (make-broadcast-stream)) is NIL
Version 1, 26-Oct-88
Status: bug report, needs no clarification?
+ KEYWORD-ARGUMENT-NAME-PACKAGE
8-NOV-87, Version 8
Status: Passed, 1988?
- LAMBDA-FORM
Version 4, 22-Nov-88, Released 8-Dec-88
Status: rejected, Jan 89 X3J13
+ LAST-N
12-MAR-88, Version 2
Status: Passed, 1988?
+ LCM-NO-ARGUMENTS
Version 1, 17 Oct 88, Released 8 Dec 88
Status: passed, Jan 89 X3J13
- LEAST-POSITIVE-SINGLE-FLOAT-NORMALIZATION
Synopsis: should LEAST-POSITIVE- and MOST-POSITIVE-XXX-FLOAT
numbers include denormalized ones in those implementations
that admit them?
Status: Not submitted
! LISP-PACKAGE-NAME
Synopsis: change LISP to COMMON-LISP to avoid CLtL confusion
Version 1, 22 Dec 88, Released 11-Jan-89
Status: tabled; version 1 still ready for vote
! LISP-SYMBOL-REDEFINITION
Version 5, 22-Nov-88, Released 8 Dec 88
Comments: Don't like (DEFVAR CAR ...) example
14: Like simpler "Redefining any documented
definition on a symbol in the LISP package -- such as variables,
functions, constants, properties and property-lists, etc -- is
undefined, except for the explicitly allowed cases (e.g. dynamic
binding of variables)."
Status: tabled; version 5 still ready for vote
- LIST-TYPE-SPECIFIER
Synopsis: add a type specifier (LIST NUMBER)
Version 1, 28 Jun 88
Status: withdrawn
! LOAD-OBJECTS
Synopsis: Provide a way to allow defstruct/defclass objects in compiled
files
Version 3, 9-Mar-89, released 16-Mar-89
Status: ready for vote?
! LOAD-TRUENAME
Synopsis: Make default pathname for LOAD inside LOAD same?
Version 1, 13-Mar-89, Released 16-Mar-89
Status: ready for vote
! LOOP-AND-DISCREPANCY
Version 1, 15-Mar-89, released 16-Mar-89
status: ready for vote
+ MACRO-FUNCTION-ENVIRONMENT
Version 2, 8-JUN-88
Status: Passed, 1988
* MACRO-SPECIAL-FORMS
Synopsis: macros expanding to implementation-dependent special forms
doesn't work
Status: not yet submitted
- MAKE-CONCATENATED-STREAM-EXAMPLE
Synopsis: (read (make-concatenated-stream (make-string-input-stream "1")
(make-string-input-stream "2"))) => 12?
Version 1, 26-Oct-88
Status: withdrawn, no issue (bug report to one implementation)
+ MAKE-PACKAGE-USE-DEFAULT
Version 2, 8 Oct 88, Released 12-Dec-88
Version 3, 16-Mar-89
Status: Passed, Jan 89 X3J13 as amended
! MAKE-STRING-FILL-POINTER
Synopsis: extend MAKE-STRING to take a fill-pointer?
Version 1, 20-Oct-88, released 16-Mar-89
Status: vote?
+ MAPPING-DESTRUCTIVE-INTERACTION
Version 2, 09-Jun-88, Released 8 Oct 88
Synopsis: [don't] define interaction of DELETE on MAPCAR'd list.
Status: passed, Jan 89 X3J13
* NTH-VALUE
Version 4, 8-Dec-88, Released 8 Dec 88
Comments: Accepted (9 to 7), with amendment to clarify what happens if n is
out of range
Status: need new version as amended
- OUTPUT-STREAM-P-EXAMPLE
Synopsis: Clarify (output-stream-p (make-concatenated-stream)) is NIL?
Version 1, 26-Oct-88
Comment: already clear; just bug report for one implementation
* PACKAGE-CLUTTER
Version 6, 12-Dec-88, Released 12-Dec-88
Comments: Accepted, with amendment that the forbidden property indicators
are
external symbols in all packages defined by this standard plus all
symbols accessible in the USER package or in packages defined by
the user.
Status: need writeup as amended
+ PACKAGE-DELETION
Version 5, 21 nov 88, Released 8 Dec 88
Comments: Minor glitches? Remove the description of "correctable" error to
be signalled and
handled.
Status: passed, Jan 89 X3J13
* PACKAGE-FUNCTION-CONSISTENCY
Synopsis: allow strings for package arg everywhere uniformly
Version 2, 12-Jan-89, Released 12-Jan-89
Comment: Accepted MORE-PERMISSIVE (v2), as amended
----- Moon 21-Jan-89 (Version 2) -----
MORE-PERMISSIVE is like PERMISSIVE except that the four
functions
identified by CLtL as "package structure accessors" that don't
allow
names are changed to allow names.
Amendments made at the meeting added DELETE-PACKAGE and
DEFPACKAGE
to the list of functions and removed the paragraph beginning
with the words "If IN-PACKAGE...".
Status: need new version as amended
* PATHNAME-CANONICAL-TYPE
Synopsis: allow canonical :SOURCE-LISP to MAKE-PATHNAME;
require PATHNAME-TYPE to return same?
Version 1, 07-Jul-88
Comments: only add the :TYPE :SOURCE-LISP, not PATHNAME-CANONICAL-TYPE?
Status: => "pathname" committee?
* PATHNAME-COMPONENT-CASE
Synopsis: allow ALL UPPER CASE to mean "use the 'right' case
Comments: lots of heat?
Status: => "pathname" committee
* PATHNAME-EXTENSIONS
Synopsis: allow a way of telling whether a pathname is a pattern, a "funny"
file
Comments: necessary in standard?
Status: => "pathname" committee
* PATHNAME-LOGICAL
Synopsis: add logical pathnames (pathnames for an imaginary portable
file system, which get translated by site-dependent translations into
physical pathnames on an actual file system)
Status: no proposal yet
* PATHNAME-PRINT-READ
Synopsis: Print pathnames like #P"asdf"?
Version 1, 21-Oct-88
Comments: Numerous, pro, con. Print like #S(pathname ...)?
Status: need new version
+ PATHNAME-STREAM
Version 6 14-NOV-87
Status: Passed, 1988?
+ PATHNAME-SYMBOL
Version 5 5-FEB-88
Status: Passed, 1988?
* PATHNAME-SUBDIRECTORY-LIST
Synopsis: How to deal with subdirectory structures in pathname functions
Version 3, 29-Dec-88
Comments: typos and proposed simplifications
Status: need new version
* PATHNAME-SYNTAX-ERROR-TIME
Synopsis: when are errors in pathnames detected?
Version 1, 7-Jul-88
Comments: various
Status: need new version
- PATHNAME-TYPE-UNSPECIFIC
Version 1 27-Jun-88, Released 7 Oct 88
Comments: may be subsumed
Status: withdrawn; superceded by PATHNAME-UNSPECIFIC-COMPONENT
* PATHNAME-UNSPECIFIC-COMPONENT
Version 1, 29-Dec-88, Released 12-Jan-89
Synopsis: More extensions to :UNSPECIFIC
Comment: Accepted (14 to 4), with amendments to allow any field to be
:UNSPECIFIC including host and name, and to say that "To use
:UNSPECIFIC in an operating system for which it does not make
sense, the results are undefined."
----- Moon 21-Jan-89 -----
RWK pointed out that :UNSPECIFIC has two meanings: the component
is omitted in this particular pathname (type in Unix) or the
component is not meaningful for this system (version in Unix).
Cross-host defaulting needs to treat those differently, so
:UNSPECIFIC can't get into a field where it is not allowed.
In the end RWK suggested people should vote for the proposal
anyway, as it was a net improvement.
Status: needs new version as amended
* PATHNAME-WILD
Version 2, 6-Oct-88
Synopsis: Portable way to ask about "wildcard" pathnames?
Comments: consistent with PATHNAME-COMPONENT-CASE?
Status: => "pathname" committee
+ PEEK-CHAR-READ-CHAR-ECHO
Version 3, 8-Oct-88, Released 8 Oct 88
Synopsis: PEEK-CHAR, READ-CHAR on streams made by MAKE-ECHO-STREAM
Status: Passed, Jan 89 X3J13
+ PRINC-CHARACTER
29-APR-87, Version 2
Status: Passed, 1988?
* PRINT-CIRCLE-SHARED
Synopsis: does *PRINT-CIRCLE* cause shared structure to print with #=?
Status: Not submitted
* PRINT-CIRCLE-STRUCTURE
Version 3, 20 Sep 88, Released 8 Oct 88
Comments: Accepted, with amendment to apply to methods on PRINT-OBJECT in
addition to :PRINT-FUNCTION options
Status: need new version as amended
* PROCLAIM-LEXICAL
Version 9, 8-Dec-88, Released 12-Dec-88
Synopsis: add LEXICAL proclaimation
Comments: lengthy mail; amendments at Jan meeting
Status: tabled, *** NEED NEW VERSION ***
+ PUSH-EVALUATION-ORDER
Version 5, 25-NOV-87
Status: Passed, 1988?
+ RANGE-OF-COUNT-KEYWORD
Version 3, 9-Oct-88, Released 14-Oct-88
Status: passed, Jan 89 X3J13
+ RANGE-OF-START-AND-END-PARAMETERS
Version 1, 14-Sep-88, Released 7 Oct 88
Status: passed, Jan 89 X3J13
* READ-CASE-SENSITIVITY
Synopsis: Allow readtables to be case sensitive
Status: ready for release???
* READ-DELIMITED-LIST-EOF
Synopsis: eof in read deliminted list signals an error
Status: awaiting submission
! REAL-NUMBER-TYPE
Synopsis: add REAL = (OR RATIONAL FLOAT) & range
Version 3, 13-Jan-89, released 16-Mar-89
Status: vote?
+ REDUCE-ARGUMENT-EXTRACTION
Version 3 13-FEB-88
Status: Passed, 1988?
* REMF-DESTRUCTION-UNSPECIFIED
Synopsis: Specification of side-effect behavior in CL
Version 2, 29-Oct-87, Released 8-Oct-88
Version 4, 29-Nov-88, Released 12-Jan-89
Status: There was a straw vote in favor of this, then BarMar was appointed
to make some amendments and put it on the letter ballot. I
think the
amendments are to tighten up NCONC and remove NBUTLAST, NSUBSTx,
and NSUBSTITUTEx.
- REMF-MULTIPLE
Synopsis: What does REMF do if it sees more than one INDICATOR?
Version 2, 12-Jan-89, Released 12-Jan-89
Status: withdrawn ("only applies in 'cannot happen' situation")
+ REQUIRE-PATHNAME-DEFAULTS
Version 6, 9 Dec 88, Released 09 Dec 88
Status: passed, Jan 89 X3j13
+ REST-LIST-ALLOCATION
Version 3, 12-Dec-88, Released 12-Dec-88
Status: proposal MAY-SHARE passed, Jan 89 X3J13
- REST-LIST-EXTENT
Synopsis: allow way to declare dynamic extent &REST
Comment: superseded by DYNAMIC-EXTENT
Status: withdrawn
+ RETURN-VALUES-UNSPECIFIED
Version 6, 9 Dec 88, Released 9-Dec-88
Status: passed, Jan 89 X3J13
+ ROOM-DEFAULT-ARGUMENT
Version 1, 12-Sep-88, Released 8 Oct 88
Status: passed, Jan 89 X3J13
- SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS
Version 6, 06-Oct-88, Released 11-Jan-89
Comments: New version scales down previously rejected version
Status: Version 6 rejected Jan 89 X3J13
! SETF-FUNCTION-VS-MACRO, SETF-PLACES, FUNCTION-NAME
Comment: either renaming or separate proposals, depending
on your point of view
SETF-FUNCTION-VS-MACRO
Version 3, 4-Nov-87, Released Nov 87
SETF-PLACES
Version 1, 11-Nov-88, Released 9-Dec-88
FUNCTION-NAME
Version 1, 27-Jan-89, Released 16-Mar-89
Status: ready for vote
* SETF-MULTIPLE-STORE-VARIABLES
Synopsis: Allow multiple "places" in SETF stores
Version 1, 5-Dec-88
Status: awaiting new version
+ SETF-SUB-METHODS
Version 5, 12-Feb-88, Released 8 Oct 88
Synopsis: careful definition of order inside (SETF (GETF ...) ...)
Status: passed, Jan 89 X3J13
+ SHADOW-ALREADY-PRESENT
Version 4 10-NOV-87
Status: Passed, 1988?
+ SHARPSIGN-PLUS-MINUS-PACKAGE
Version 3 14-NOV-87
Status: Passed, 1988?
* SINGLE-FLOAT-NON-PORTABLE
Synopsis: remove SINGLE-FLOAT, DOUBLE-FLOAT a la FIXNUM?
Status: Not submitted
+ SPECIAL-TYPE-SHADOWING
Synopsis: intersection of types when proclaimed special has local type
declaration
Version 1, 4-Nov-88, released 11-Jan-89
Status: passed, Jan 89 X3J13
SPECIAL-VARIABLE-TEST
Synopsis: Add SPECIAL-VARIABLE-P?
Version 2, 31-May-88
Status: "On hold pending SYNTACTIC-ENVIRONMENT-ACCESS"
+ STANDARD-INPUT-INITIAL-BINDING
Version 8, 8 Jul 88, Released 7 Oct 88
Status: passed, Jan 89 X3J13
* STANDARD-VALUE
Synopsis: user can say binding is "temporary"
Version 1, 21-Oct-88
Comments: not worth trying to standardize now?
Status: ready for release?
* STEP-ENVIRONMENT
Version 3, 20-Jun-88, Released 7 Oct 88
Comments: Passed, Jan 89.
Verbally this was explained to mean that the body of the STEP would
not be stepped when compiled, but if it just happened to call an
interpreted function, that function would get stepped. Also the
word "evaluation" in that sentence was amended to "computation."
Status: need new version as amended
+ STREAM-ACCESS
Version 2, 30-Nov-88, Released 9 Dec 88
Status: ADD-TYPES-ACCESSORS passed, Jan 89 X3J13
* STREAM-CAPABILITIES
Version 1, 7/5/88
Synopsis: SAME-SOURCE-P, SAME-DESTINATION-P, etc
Status: awaiting new version, from "pathname/file" committee?
* STREAM-DEFINITION-BY-USER
Synopsis: Want user-definable stream types.
Status: not submitted
* STREAM-ELEMENT-TYPE-EXAMPLES
Version 1, 26-Oct-88
Synopsis: clarify STREAM-ELEMENT-TYPE may return different values?
Status: editorial? Need new proposal?
- STREAM-INFO
Version 6, 30-Nov-88, Released 9 dec 88
Status: Rejected, Jan 89 X3J13
+ SUBSEQ-OUT-OF-BOUNDS
29-MAR-88 Version 2
Status: Passed, 1988?
* SUBTYPEP-ENVIRONMENT
SUBTYPEP-EMPTY-NIL
Version 1
Status: => editorial, no cleanup needed
+ SUBTYPEP-TOO-VAGUE
Version 4, 7-Oct-88, Released 7 Oct 88
Status: passed, Jan 89 X3J13
* SYMBOL-MACROFLET
Version 1, 30 Sep 88
Synopsis: Add SYMBOL-MACROFLET gives lexical function expansion
Status: need new version
+ SYMBOL-MACROLET-DECLARE
Version 2, 9-Dec-88, Released 9 Dec 88
Status: passed, Jan 89 X3J13
!+ SYMBOL-MACROLET-SEMANTICS
Version 5, 30-Nov-88, Released 9 Dec 88
Status: Passed, Jan 89 X3J13
Version 6, 14-Mar-89, released 16-Mar-89
Status: ready for vote
- TAGBODY-CONTENTS
Version 5, 9-Dec-88, Released 9 Dec 88
Comments: "good that this failed, but we still need a clarification"
Status: Failed, Jan 89 X3J13
+ TAILP-NIL
Version 5, 9-Dec-88, Released 12-Dec-88
Synopsis: Operation of TAILP given NIL
Status: passed, Jan 89 X3J13
* TEST-NOT-IF-NOT
Version 3, 1 Dec 88, Released 9 dec
Comments: passed, Jan 89 X3J13 FLUSH-ALL, amended to deprecate instead of
removing
Status: Need new version as amended.
* THE-AMBIGUITY
Version 2, 11-Jan-89, Released 11-Jan-89
Comments: typo, sense wrong
Status: tabled
! TIME-ZONE-NON-INTEGER
Version 1, 13-Mar-89, Released 16-Mar-89
Status: ready for vote
- TRACE-ERROR
Synopsis: TRACE should signal errors if it doesn't understand
Version 1, 20-Jun-88
Comments: is this a cleanup?
Status: withdrawn
- TRACE-FUNCTION-ONLY
Synopsis: extend TRACE to handle other specs
Comment: we don't like it
Status: withdrawn
* TRUENAME-SYNTAX-ONLY
Version 1, 12-Sep-88
Synopsis: when does TRUENAME perform checking?
Comments: other options? leave more vague? Other questions?
Status: need new version => "pathname" committee
+* TYPE-OF-UNDERCONSTRAINED
Version 3, 12-Dec-88, Released 12 Dec 88
Comments: Accepted, with amendments
Version 5, 16-Mar-89
Status: Ready for release?
Status: need new version as amended
* TYPE-SPECIFIER-PREDICATE
Synopsis: "Add a new function TYPE-SPECIFIER-P that is true of valid type
specifiers and false of all other Lisp objects. Note that the use of
DEFSTRUCT and DEFTYPE can change the behavior of TYPE-SPECIFIER-P over
time."
Comments: considerable discussion on common lisp mailing list.
Status: Not yet submitted
* UNDEFINED-VARIABLES-AND-FUNCTIONS
Synopsis: What happens on an undefined function call, unbound variable ref?
Version 1, 29-Nov-88, Released 11-Jan-89
Comments: Lumping SLOT-UNBOUND in with unbound special variables was a
mistake,
as SLOT-UNBOUND is an extension mechanism, not only a safety
checking
mechanism. Also there were some wording problems. Gabriel and
Gregor
are to submit a revised proposal.
Status: pending
+ UNREAD-CHAR-AFTER-PEEK-CHAR
Version 2, 2-Dec-88, Released 12-Dec-88
Status: passed, Jan 89 X3J13
+ VARIABLE-LIST-ASYMMETRY
Version 3, 08-Oct-88, Released 9 Dec 88
Status: passed, Jan 89 X3J13
+ WITH-OUTPUT-TO-STRING-APPEND-STYLE
Version 5, 7-JUN-88
Status: Passed, 1988?
----- End Forwarded Messages -----
----- End Forwarded Messages -----
----- End Forwarded Messages -----
----- End Forwarded Messages -----
----- End Forwarded Messages -----
----- End Forwarded Messages -----
----- End Forwarded Messages -----
∂17-Mar-89 0823 CL-Cleanup-mailer Re: DEFAULT-CASE
Received: from SEF1.SLISP.CS.CMU.EDU by SAIL.Stanford.EDU with TCP; 17 Mar 89 08:23:49 PST
Received: from SEF1.SLISP.CS.CMU.EDU by SEF1.SLISP.CS.CMU.EDU; 17 Mar 89 11:19:44 EST
To: franz!frisky!jkf@ucbarpa.Berkeley.EDU (John Foderaro)
cc: cl-cleanup@sail.stanford.edu
Subject: Re: DEFAULT-CASE
In-reply-to: Your message of Thu, 16 Mar 89 21:38:14 -0800.
<8903170538.AA09727@frisky>
Date: Fri, 17 Mar 89 11:19:37 EST
From: Scott.Fahlman@B.GP.CS.CMU.EDU
I'm not trying to start a religious war. I'm not saying that
case-sensitive is better or worse than case-insensitive. I'm just
saying that there are large numbers of people who favor each position
and that Common Lisp should support both.
I'm trying to stay out of most cleanup discussions these days, but feel
compelled to say something about this one, especially since John indicated
that he was reading silence as non-disagreement.
The argument here is that we should make it easy for those people who
prefer case-sensitivity to write their code that way and for those who like
case-insensitivity (with symbols being bashed into some canonical case) to
write their code that way. I think that this is a recipe for consfusion
and major portability problems. As soon as there is code around that
assumes case sensitivity, anyone who wants to use that code in conjuction
with code of his own has to go along with case sensitivity. Attempts to
mix the two styles will break. It would be like the old days when half the
Lisp world used octal and the other half used decimal. So if this measure
is adopted, it won't be a matter of "freedom of choice". We'll either have
two incompatible software words within Common Lisp, or it will drag us all
through a major incompatible change we don't want.
I think we have to choose one style or the other for code if portability is
to be maintained. For better or for worse, we made that choice in favor of
a case-bashing convention. I don't think I'd favor the same choice again
if compatibility with the past were not an issue, but I don't think we can
make such a sweeping incompatible change now. And we can't straddle the
fence.
I've got no problem with a proposal that would allow the Common Lisp reader
to go into some non-case-smashing mode. This would be useful when the
reader is reading code for some embedded language with different case
rules, building up a dtabase, or doing other tasks. But we should make it
clear that when reading Common Lisp code, the case-bashing convention still
holds.
-- Scott
∂17-Mar-89 0838 CL-Cleanup-mailer Issue: FUNCTION-COERCE-TIME (Version 2)
Received: from Think.COM by SAIL.Stanford.EDU with TCP; 17 Mar 89 08:38:32 PST
Return-Path: <barmar@Think.COM>
Received: from OCCAM.THINK.COM by Think.COM; Fri, 17 Mar 89 11:34:48 EST
Date: Fri, 17 Mar 89 11:35 EST
From: Barry Margolin <barmar@Think.COM>
Subject: Issue: FUNCTION-COERCE-TIME (Version 2)
To: cl-cleanup@sail.stanford.edu
Cc: Masinter.pa@xerox.com
In-Reply-To: <890316-221804-6820@Xerox>
Message-Id: <19890317163539.1.BARMAR@OCCAM.THINK.COM>
I favor LAZY, and then HYBRID. I don't think performance is a
significant issue, as programmers can always get ambitious semantics by
specifying #'symbol or (symbol-function 'symbol) explicitly instead of
'symbol. I believe that anyone who specifies the symbol instead of the
function is doing it precisely for its lazy semantics.
I like LAZY best because it makes all functions that take functional
arguments consistent.
barmar
∂17-Mar-89 0847 CL-Cleanup-mailer Re: DEFAULT-CASE
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 17 Mar 89 08:47:29 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 559518; Fri 17-Mar-89 11:44:50 EST
Date: Fri, 17 Mar 89 11:44 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: DEFAULT-CASE
To: John Foderaro <franz!frisky!jkf@ucbarpa.Berkeley.EDU>
cc: CL-Cleanup@sail.stanford.edu
In-Reply-To: <8903170538.AA09727@frisky>
Message-ID: <19890317164453.4.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Thu, 16 Mar 89 21:38:14 PST
From: franz!frisky!jkf@ucbarpa.Berkeley.EDU (John Foderaro)
I'm not trying to start a religious war. I'm not saying that
case-sensitive is better or worse than case-insensitive. I'm just
saying that there are large numbers of people who favor each position
and that Common Lisp should support both.
Agreed. I'm trying to help you not start a religious war.
Regarding internal vrs external: The internal representation shows
through in a number of places. For example the functions symbol-name
and make-symbol let the user deal with the actual internal
representation of the names of symbols. The idea of having a
*print-case* value that inverts the case on output is interesting but
that would make things awkward: To make the symbol FooBar you
would have to (make-symbol "fOObAR"). Also examining the characters
of a print-name with aref would give confusing results.
The internal representation is accessible to programs, but I don't think
it's particularly important. You seem to disagree. It might be that we
have different experience with how often these primitives are used in
portable programs. I don't think they are used enough that having an
internal representation in the opposite case from the external one would
cause bugs, but I do think they are used often enough that an incompatible
change would cause bugs in the medium term.
>> I also claim that the choice of case in internal representation
>> is arbitrary and need not prejudice the external representation
>> at all.
For a case-insensitive Lisp I completely agree. For a case-sensitive
Lisp, as I've shown above, this just isn't true. Thus if the needs
of the case-sensitive Lisp are met, then the needs of both are met.
True, but if the discussion gets side-tracked by flaming controversy over
the relatively unimportant issue of internal representation, I suspect
that the only outcome will be that everyone will give up on reaching a
concensus and we will be stuck with the status quo. On the other hand,
if you compromise and keep the internal representation compatible, I
predict that you can very easily get what you really want, at the cost
of having a language 0.01% more inelegant than it would otherwise be.
∂17-Mar-89 0859 CL-Cleanup-mailer Re: issue HASH-TABLE-PRINTED-REPRESENTATION, v.2
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 17 Mar 89 08:59:00 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 17 MAR 89 08:53:42 PST
Date: 17 Mar 89 08:52 PST
From: masinter.pa@Xerox.COM
Subject: Re: issue HASH-TABLE-PRINTED-REPRESENTATION, v.2
In-reply-to: Dave.Touretzky@B.GP.CS.CMU.EDU's message of Fri, 09 Dec 88
04:43:36 EST
To: Dave.Touretzky@cs.cmu.edu, cl-cleanup@sail.stanford.edu
cc: masinter.pa@Xerox.COM
Message-ID: <890317-085342-8373@Xerox>
If someone brings a new draft to the March 89 X3J13, we can
put it on the agenda and discuss it.
- - - - - - - -
Return-Path: <CL-Cleanup-mailer@SAIL.Stanford.EDU>
Redistributed: xerox-cl-cleanup↑.pa
Received: from SAIL.Stanford.EDU ([36.86.0.194]) by Xerox.COM ; 08 DEC 88 12:24:47 PST
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 8 Dec 88 12:21:22 PST
Received: from Semillon.ms by ArpaGateway.ms ; 08 DEC 88 12:00:50 PST
Date: 8 Dec 88 12:00 PST
From: masinter.pa
Subject: Re: issue HASH-TABLE-PRINTED-REPRESENTATION
In-reply-to: masinter.pa's message of 14 Nov 88 15:50 PST
To: cl-cleanup@sail.stanford.edu, Dave.Touretzky@B.GP.CS.CMU.EDU
Message-ID: <881208-120050-4123@Xerox>
I like Kent's idea
" I (KMP) made a note to myself that since #S(ARRAY ...) and
#S(HASH-TABLE ...) couldn't possibly be meaningful, one might define
#S to be the generalized constructor for things other than structures.
So #S(ARRAY ...) could be used to print arrays with attributes that
would otherwise be lost. eg, #S(ARRAY :CONTENTS ... :FILL-POINTER ...).
Similarly, #S(HASH-TABLE :CONTENTS ... :SIZE ...) for the cases where
hairy options wanted to be shown. #A and the simpler #H notation could
then be used unless some option variable were set that said to really
print the full-blown info."
However, this issue is not going anywhere -- there were certainly
more No's than Yes's to proceed with the latest draft.
Return-Path: <Dave.Touretzky@dst.boltz.cs.cmu.edu>
Received: from DST.BOLTZ.CS.CMU.EDU ([128.2.220.61]) by Xerox.COM ; 09 DEC 88 01:44:26 PST
Received: from DST.BOLTZ.CS.CMU.EDU by DST.BOLTZ.CS.CMU.EDU; 9 Dec 88 04:43:48 EST
To: masinter.pa
cc: cl-cleanup@sail.stanford.edu
Reply-To: Dave.Touretzky@cs.cmu.edu
Subject: Re: issue HASH-TABLE-PRINTED-REPRESENTATION
In-reply-to: Your message of 08 Dec 88 12:00:00 -0800.
<881208-120050-4123@Xerox>
Date: Fri, 09 Dec 88 04:43:36 EST
Message-ID: <3932.597663816@DST.BOLTZ.CS.CMU.EDU>
From: Dave.Touretzky@B.GP.CS.CMU.EDU
I like KMP's idea too. In fact, if KMP's extension to #S were passed, I
would be happy to shelve the #H proposal. I want hash tables to have a
READable printed representation, but I don't want to squander the remaining
# macro dispatch characters on obscure bits of syntax. People will want to
type in arrrays as constants (with #A) much more frequently than hash
tables, so #A is needed but #H is diposable.
-- Dave
∂17-Mar-89 0910 CL-Cleanup-mailer Re: Issue: COERCE-INCOMPLETE (Version 3)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 17 Mar 89 09:09:51 PST
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 559547; Fri 17-Mar-89 12:05:36 EST
Date: Fri, 17 Mar 89 12:05 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: Issue: COERCE-INCOMPLETE (Version 3)
To: sandra%defun@cs.utah.edu
cc: barmar@Think.COM, KMP@STONY-BROOK.SCRC.Symbolics.COM,
masinter.pa@xerox.com, CL-Cleanup@SAIL.Stanford.EDU
In-Reply-To: <8903171654.AA06800@defun.utah.edu>
Message-ID: <890317120519.8.KMP@BOBOLINK.SCRC.Symbolics.COM>
[X3J13 removed as overkill for this level of discussion; CL-Cleanup added]
Date: Fri, 17 Mar 89 09:54:35 MST
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
... BarMar is right. I have a hardcopy of the FUNCTION-TYPE writeup that
was mailed on 4 Sep 88, with a note from Larry indicating that it's
the final version as passed at the June meeting. It includes
COERCE'ing of lambda expressions to functions as item 6b. ...
Yeah, it's the same in my copy. Sorry about that. I just stopped reading
too soon. Thanks for catching this.
I don't think this is a valid argument for not getting rid of COERCE,
since it is easy to coerce a lambda expression to a function using
(EVAL `(FUNCTION ,x)).
I mostly agree, but I admit that most other coercion operators don't force
you to cons unnecessary intermediate structure in order to do the coercion.
Having something like the original SCHEME's ENCLOSE operator wouldn't bother
me at all. Too bad we didn't pick the name DISCLOSE for what ended up being
FUNCTION-LAMBDA-EXPRESSION. I guess the right name for the ENCLOSE function
at this point is LAMBDA-EXPRESSION-FUNCTION.
∂17-Mar-89 1032 CL-Cleanup-mailer DYNAMIC-EXTENT
Received: from REAGAN.AI.MIT.EDU by SAIL.Stanford.EDU with TCP; 17 Mar 89 10:32:06 PST
Received: from ISABEL-PERON.AI.MIT.EDU by REAGAN.AI.MIT.EDU via CHAOS with CHAOS-MAIL id 182328; Fri 17-Mar-89 13:26:45 EST
Date: Fri, 17 Mar 89 13:29 EST
From: Richard Mlynarik <Mly@AI.AI.MIT.EDU>
Subject: DYNAMIC-EXTENT
To: CL-Cleanup@sail.stanford.edu
In-Reply-To: <890316-120057-5042@Xerox>
Message-ID: <19890317182930.6.MLY@ISABEL-PERON.AI.MIT.EDU>
I don't see any way in the proposal to declare that a closure itself, rather than
its arguments, has dynamic extent. My greatest single use for dynamic-extent
declarations is to ensure stack-consing of closures.
Symbolics have a declaration SYS:DOWNWARD-FUNCTION for this case.
Perhaps CL could use DYNAMIC-EXTENT-FUNCTION
(flet ((test (a b)
(declare (dynamic-extent-function))
...))
(foo #'test))
(foo (lambda (a b)
(declare (dynamic-extent-function))
...))
Another feature which I find sorely needed (and which nobody seems
to support) is a way to declare that the result of a form
has dynamic extent. For example,
(defmacro with-frob (thunk &body body)
`(let ((*frob-stack* (cons (the dynamic-extent-object ,thunk) *frob-stack*)))
(declare (dynamic-extent *frob-stack*))
,@body))
The idea is to avoid making all users of the with-frob macro
put in explicit dynamic-extent-function declarations.
∂17-Mar-89 1044 CL-Cleanup-mailer Re: DEFAULT-CASE
Received: from NSS.Cs.Ucl.AC.UK by SAIL.Stanford.EDU with TCP; 17 Mar 89 10:43:34 PST
Received: from aiai.edinburgh.ac.uk by NSS.Cs.Ucl.AC.UK via Janet with NIFTP
id aa08901; 17 Mar 89 18:19 GMT
Date: Fri, 17 Mar 89 18:18:11 GMT
Message-Id: <4955.8903171818@subnode.aiai.ed.ac.uk>
From: Jeff Dalton <jeff%aiai.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK>
Subject: Re: DEFAULT-CASE
To: "David A. Moon" <Moon@scrc-stony-brook.arpa>,
John Foderaro <@NSS.Cs.Ucl.AC.UK,@aiai.edinburgh.ac.uk,@ucbarpa.berkeley.edu,@franz:jkf@frisky>
In-Reply-To: David A. Moon's message of Thu, 16 Mar 89 18:15 EST
Cc: CL-Cleanup@sail.stanford.edu
> Proposal (DEFAULT-CASE:LOWER)
>
> The case of all characters in the names of standard
> functions, symbols, and packages is lower.
>
> You're proposing a huge incompatible change that is bound to
> get you into a religious war that can't do anyone any good.
> I claim that this proposal addresses the internal representation
> of programs but all you care about is the external representation.
> I also claim that the choice of case in internal representation
> is arbitrary and need not prejudice the external representation
> at all.
That is almost true, but not compeletly. What about FIND-SYMBOL and
the like? So the programmer sometimes still has to know that, internally,
the default is upper case. And if the internal case has so little
significance, why should there be a religious war about it?
> If you believe what I just said, you would propose that the reader get
> an option to flip case instead of up-casing when converting from
> external representation to internal representation, and would propose
> another value for *print-case* that does the inverse transformation.
Something like this was suggested in the "discussion" section of
READ-CASE-SENSITIVITY (Version 1). But maybe it shouldn't just
flip everything:
An interesting possibility would be to disguise the preferred
internal case by defining a value for *READ-CASE* called :INVERT.
If the value were :INVERT, mixed-case symbols would remain the same
(or perhaps they would be inverted too) but all-upper-case input
would specify a lower-case name internally, and vice versa.
One problem with such proposals is that (I suspect) most people
most of the time will write code in lower case. Having the reader
always invert what they type seems a bit perverse. I'd be surprised
if this convinced anyone to change their mind, though.
> This would be compatible with everybody, would make everybody happy
> except for those who might insist that one internal representation
> is better than the other, and hopefully would avoid spending a lot
> of time on discussion. What do you think?
I'd prefer to change the internal case, but this is a reasonable
alternative if a change can't happen or would cause hard feelings
or extensive difficulty if it did.
∂17-Mar-89 1046 CL-Cleanup-mailer Re: issue PROCLAIM-LEXICAL (Version 9)
Received: from NSS.Cs.Ucl.AC.UK by SAIL.Stanford.EDU with TCP; 17 Mar 89 10:46:17 PST
Received: from aiai.edinburgh.ac.uk by NSS.Cs.Ucl.AC.UK via Janet with NIFTP
id aa08933; 17 Mar 89 18:26 GMT
Date: Fri, 17 Mar 89 18:25:09 GMT
Message-Id: <5014.8903171825@subnode.aiai.ed.ac.uk>
From: Jeff Dalton <jeff%aiai.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK>
Subject: Re: issue PROCLAIM-LEXICAL (Version 9)
To: "David A. Moon" <Moon@scrc-stony-brook.arpa>, masinter.pa@xerox.com
In-Reply-To: David A. Moon's message of Thu, 16 Mar 89 12:29 EST
Cc: cl-cleanup@sail.stanford.edu
> Maybe I shouldn't take this attitude, but I will anyway. I have brief
> notes on the amendments that were proposed, but since I think all of them
> were wrongheaded and braindamaged, I'm not going to help anyone remember
> them. Only one of the amendments was actually voted on, so we're certainly
> free to forget the other two.
I didn't much like the ammendments either. They were drafted on the
spot and probably not very well thought-out.
However, it would be nice to know if there are still strong objections
to version 9 (and what they are if they exist) so there will be time
to consider them before the meeting.
∂17-Mar-89 1100 CL-Cleanup-mailer Issue: CONDITION-RESTARTS (Version 1)
Received: from REAGAN.AI.MIT.EDU by SAIL.Stanford.EDU with TCP; 17 Mar 89 11:00:09 PST
Received: from ISABEL-PERON.AI.MIT.EDU by REAGAN.AI.MIT.EDU via CHAOS with CHAOS-MAIL id 182335; Fri 17-Mar-89 13:54:53 EST
Date: Fri, 17 Mar 89 13:57 EST
From: Richard Mlynarik <Mly@AI.AI.MIT.EDU>
Subject: Issue: CONDITION-RESTARTS (Version 1)
To: cl-cleanup@sail.stanford.edu
In-Reply-To: <890314-082536-2261@Xerox>
Message-ID: <19890317185733.7.MLY@ISABEL-PERON.AI.MIT.EDU>
Date: 14 Mar 89 08:24 PST
From: masinter.pa@xerox.com
Your thoughts?
----- Begin Forwarded Messages -----
[...]
The proposal doesn't compensate for the mistake of having
disassociated restarts from context in the first place.
All restarts should have associated with them a real predicate
(not just a screwy wired-in (lambda (c) (eq c associated-condition)))
In general the applicability of a restart depends on the dynamic
environment in which it invoked as well as that in which it
was established.
All restarting forms should require a condition argument (-not- NIL.)
Why on earth do ABORT, USE-VALUE, etc still exist?
The business about COPY-CONDITION is completely confused.
I don't care for the syntax, though it isn't worse than
that of the rest of the condition system.
∂17-Mar-89 1101 CL-Cleanup-mailer Issue: CONDITION-RESTARTS (Version 1)
Received: from REAGAN.AI.MIT.EDU by SAIL.Stanford.EDU with TCP; 17 Mar 89 11:01:07 PST
Received: from ISABEL-PERON.AI.MIT.EDU by REAGAN.AI.MIT.EDU via CHAOS with CHAOS-MAIL id 182336; Fri 17-Mar-89 13:55:49 EST
Date: Fri, 17 Mar 89 13:58 EST
From: Richard Mlynarik <Mly@AI.AI.MIT.EDU>
Subject: Issue: CONDITION-RESTARTS (Version 1)
To: cl-cleanup@sail.stanford.edu
In-Reply-To: <890314-082536-2261@Xerox>
Supersedes: <19890317185733.7.MLY@ISABEL-PERON.AI.MIT.EDU>
Message-ID: <19890317185835.8.MLY@ISABEL-PERON.AI.MIT.EDU>
From: masinter.pa@xerox.com
Subject: Issue: CONDITION-RESTARTS (Version 1)
To: Richard Mlynarik <Mly@ai.ai.mit.edu>, Daniels.PA@xerox.com
Reply-To: cl-cleanup@sail.stanford.edu
Your thoughts?
----- Begin Forwarded Messages -----
[...]
The proposal doesn't compensate for the mistake of having
disassociated restarts from context in the first place.
All restarts should have associated with them a real predicate
(not just a screwy wired-in (lambda (c) (eq c associated-condition)))
In general the applicability of a restart depends on the dynamic
environment in which it invoked as well as that in which it
was established.
All restarting forms should require a condition argument (-not- NIL.)
Why on earth do ABORT, USE-VALUE, etc still exist?
The business about COPY-CONDITION is completely confused.
I don't care for the syntax, though it isn't worse than
that of the rest of the condition system.
∂17-Mar-89 1205 CL-Cleanup-mailer Issue: IN-SYNTAX (Version 1)
Received: from Think.COM by SAIL.Stanford.EDU with TCP; 17 Mar 89 12:05:22 PST
Received: from fafnir.think.com by Think.COM; Fri, 17 Mar 89 15:01:32 EST
Return-Path: <gls@Think.COM>
Received: from verdi.think.com by fafnir.think.com; Fri, 17 Mar 89 15:02:43 EST
Received: by verdi.think.com; Fri, 17 Mar 89 14:59:31 EST
Date: Fri, 17 Mar 89 14:59:31 EST
From: Guy Steele <gls@Think.COM>
Message-Id: <8903171959.AA09035@verdi.think.com>
To: masinter.pa@xerox.com
Cc: KMP@stony-brook.scrc.symbolics.com, CL-Cleanup@sail.stanford.edu
In-Reply-To: masinter.pa@xerox.com's message of 16 Mar 89 23:05 PST <890316-230556-6907@Xerox>
Subject: Issue: IN-SYNTAX (Version 1)
Yet Another Puppy--YAP!
So let us define a "yapper" to mean someone who proposes Yet Another Puppy.
--Q
∂17-Mar-89 1214 CL-Cleanup-mailer Issue LOOP-AND-DISCREPANCY, version 1
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 17 Mar 89 12:14:03 PST
Received: from bhopal ([192.9.200.13]) by heavens-gate.lucid.com id AA01428g; Wed, 15 Mar 89 23:55:31 PST
Received: by bhopal id AA11642g; Wed, 15 Mar 89 23:56:18 PST
Date: Wed, 15 Mar 89 23:56:18 PST
From: Jon L White <jonl@lucid.com>
Message-Id: <8903160756.AA11642@bhopal>
To: gls@Think.COM
Cc: cl-cleanup@sail.stanford.edu
In-Reply-To: Guy Steele's message of Wed, 15 Mar 89 13:50:51 EST <8903151850.AA02865@verdi.think.com>
Subject: Issue LOOP-AND-DISCREPANCY, version 1
The document 89-004 followed what the code does (the "code" being that
portable version that used to come from MIT), but at the Hawaii meeting,
I remember suggesting that it ought to be made formal as to whether or not
the WITH or the FOR/AS is to be repeated. I'm glad you took the time to
write up the issue (which I approve of). It's really a very minor point,
so there is very little risk involved.
-- JonL --
∂17-Mar-89 1214 CL-Cleanup-mailer Issue: ADJUST-ARRAY-NOT-ADJUSTABLE (Version 6)
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 17 Mar 89 12:14:13 PST
Received: from bhopal ([192.9.200.13]) by heavens-gate.lucid.com id AA01417g; Wed, 15 Mar 89 23:39:01 PST
Received: by bhopal id AA11617g; Wed, 15 Mar 89 23:39:49 PST
Date: Wed, 15 Mar 89 23:39:49 PST
From: Jon L White <jonl@lucid.com>
Message-Id: <8903160739.AA11617@bhopal>
To: gls@Think.COM
Cc: masinter.pa@xerox.com, cl-cleanup@sail.stanford.edu
In-Reply-To: Guy Steele's message of Tue, 28 Feb 89 14:13:37 EST <8902281913.AA03555@verdi.think.com>
Subject: Issue: ADJUST-ARRAY-NOT-ADJUSTABLE (Version 6)
re: I conclude that the strict interpretation may be preferred, but not for the
reasons Jonl has advanced! The liberal interpretation does *not* prevent
compilers for stock hardware from producing good code, and therefore the
code example does not support his claim to the contrary.
Guy, I fear that you have made an error of logic in analyzing my example.
You use the "strict" interpretation to conclude that the example is
incorrect code (as it should be!); but the whole point of the example is
to show that under the "liberal" interpretation, it's correctness depends
on the implementation rather than on a implementation-independent definition.
If you don't see this, then perhaps we should talk about it "off line".
-- JonL --
∂17-Mar-89 1214 CL-Cleanup-mailer Issue: ADJUST-ARRAY-NOT-ADJUSTABLE (Version 8)
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 17 Mar 89 12:14:37 PST
Received: from bhopal ([192.9.200.13]) by heavens-gate.lucid.com id AA01413g; Wed, 15 Mar 89 23:32:00 PST
Received: by bhopal id AA11607g; Wed, 15 Mar 89 23:32:47 PST
Date: Wed, 15 Mar 89 23:32:47 PST
From: Jon L White <jonl@lucid.com>
Message-Id: <8903160732.AA11607@bhopal>
To: cl-cleanup@sail.stanford.edu
Cc: X3J13@Sail.stanford.edu
In-Reply-To: masinter.pa@Xerox.COM's message of 15 Mar 89 05:13 PST <890315-051405-3472@Xerox>
Subject: Issue: ADJUST-ARRAY-NOT-ADJUSTABLE (Version 8)
Although I haven't had time to join the overly-lengthy discussion on this
matter, I did point out one particularly confusing direction -- that this
proposal to "fix" the function ADJUST-ARRAY has become a proposal to alter
the semantics of the type SIMPLE-ARRAY. Compare CLtL, p28, with the
sentence in the Rationale Section:
"Specifying the points left unspecified (requiring all simple arrays to be
non-adjustable and all adjustable arrays to be non-simple) would require
large changes to some implementations and would be of little benefit to
..."
and with an item in the Clarification section:
"a. Whether an array can be both simple and adjustable is unspecified."
[CLtL definition *does* specify it].
I suggested that a simple statement be added to the proposal as follows:
"This proposal does not attempt to alter the meaning of the type
SIMPLE-ARRAY in any way"
Moon expressed approval of adding that statement.
Altered semantics would mean that it is no longer a portable type. I
have sent out several trivially small examples that show this. Some
people have interpreted those examples as simply showing what happens
with "broken" code; but quite to the contrary, they show how code can be
"correct" on one implementation and "broken" on another ****** when the
definition of SIMPLE-ARRAY is allowed to vary between one implementation
and the other ******. Very carefully, CLtL spells out that implementations
may vary on the efficiency with which they implement SIMPLE-ARRAYS; but
nowhere does it provide for optional exclusion of some parts of the
definition thereof.
Also, I note that all of the discussion on the Cl-cleanup list was by
persons other than the half-dozen or so maintainers of "stock hardware"
compilers. I personally spoke with three others (not including myself)
at Hawaii, and we all have identical requirements for the type SIMPLE-ARRAY,
and identical resolve that it must not be changed. Our compilers will
continue to offer this C-level optimization capability; the only
question is whether or not the CL1989 Standard will be cognizant of it.
-- JonL --
∂17-Mar-89 1229 CL-Cleanup-mailer DYNAMIC-EXTENT
Received: from Think.COM by SAIL.Stanford.EDU with TCP; 17 Mar 89 12:27:59 PST
Received: from fafnir.think.com by Think.COM; Fri, 17 Mar 89 15:23:26 EST
Return-Path: <gls@Think.COM>
Received: from verdi.think.com by fafnir.think.com; Fri, 17 Mar 89 15:24:37 EST
Received: by verdi.think.com; Fri, 17 Mar 89 15:21:24 EST
Date: Fri, 17 Mar 89 15:21:24 EST
From: Guy Steele <gls@Think.COM>
Message-Id: <8903172021.AA09135@verdi.think.com>
To: Mly@ai.ai.mit.edu
Cc: CL-Cleanup@sail.stanford.edu
In-Reply-To: Richard Mlynarik's message of Fri, 17 Mar 89 13:29 EST <19890317182930.6.MLY@ISABEL-PERON.AI.MIT.EDU>
Subject: DYNAMIC-EXTENT
Date: Fri, 17 Mar 89 13:29 EST
From: Richard Mlynarik <Mly@ai.ai.mit.edu>
I don't see any way in the proposal to declare that a closure itself, rather than
its arguments, has dynamic extent. My greatest single use for dynamic-extent
declarations is to ensure stack-consing of closures.
Symbolics have a declaration SYS:DOWNWARD-FUNCTION for this case.
Perhaps CL could use DYNAMIC-EXTENT-FUNCTION
(flet ((test (a b)
(declare (dynamic-extent-function))
...))
(foo #'test))
(foo (lambda (a b)
(declare (dynamic-extent-function))
...))
This is a genuine need. I suggest
(flet ((test (a b) ...))
(declare (dynamic-fextent test)) ;So pick a better name
(foo #'test))
Another feature which I find sorely needed (and which nobody seems
to support) is a way to declare that the result of a form
has dynamic extent. For example,
(defmacro with-frob (thunk &body body)
`(let ((*frob-stack* (cons (the dynamic-extent-object ,thunk) *frob-stack*)))
(declare (dynamic-extent *frob-stack*))
,@body))
The idea is to avoid making all users of the with-frob macro
put in explicit dynamic-extent-function declarations.
This proposal has problems. It is not enough to say
"foo has dynamic extent extent". You have to say something
about when it starts and ends. For executable constructs
we implicitly refer to the time execution enters the
construct and the time execution leaves it. For objects
it is more difficult, and I claim you need to tie it to
code execution. How do I know that the "thunk" is supposed
to last for the duration of the LET, rather than just the
duration of the call to CONS, or the duration of the caller
of the macro?
--Guy
∂17-Mar-89 1254 CL-Cleanup-mailer Re: DEFAULT-CASE
Received: from ucbarpa.Berkeley.EDU by SAIL.Stanford.EDU with TCP; 17 Mar 89 12:54:27 PST
Received: from franz.UUCP by ucbarpa.Berkeley.EDU (5.61/1.33)
id AA10420; Fri, 17 Mar 89 12:23:10 -0800
Received: from frisky by franz (3.2/3.14)
id AA24300; Fri, 17 Mar 89 11:37:25 PST
Received: by frisky (3.2/3.14)
id AA11169; Fri, 17 Mar 89 11:36:17 PST
From: franz!frisky!jkf@ucbarpa.Berkeley.EDU (John Foderaro)
Return-Path: <frisky!jkf>
Message-Id: <8903171936.AA11169@frisky>
To: franz!ucbarpa!B.GP.CS.CMU.EDU!Scott.Fahlman
Cc: franz!sail.stanford.edu!cl-cleanup
Subject: Re: DEFAULT-CASE
In-Reply-To: Your message of Fri, 17 Mar 89 11:19:37 EST.
<8903171622.AA04031@ucbarpa.Berkeley.EDU>
Date: Fri, 17 Mar 89 11:36:14 PST
Scott,
I completely agree that all 'official' Common Lisp symbol names should
be use one case, and should there ever be a library of contributed programs
only those program that work in a case-insensitive mode should be
accepted. When Common Lisp starts up it should be case-insensitive
just like it is now.
>> I think that this is a recipe for confusion
>> and major portability problems. As soon as there is code around that
>> assumes case sensitivity, anyone who wants to use that code in conjunction
>> with code of his own has to go along with case sensitivity.
This is incorrect. I've had ten years of experience with using
code written in both case-sensitive and insensitive-modes in the same Lisp
(first it was debugging Macsyma in Franz Lisp, and now it is working
with programs like PCL in Common Lisp). The only difficulties
I had were due to the default case of symbol names (and that is what
my proposal is directed to fix). Keep in mind that if you
decide to live solely in the case-insensitive world you still have
access to all symbols, you may just have to type extra backslashes or
vertical bars sometimes.
>> We'll either have two incompatible software words within Common Lisp,
>> or it will drag us all through a major incompatible change we don't want.
I honestly don't know what you mean by this. Perhaps you could describe some
of your experiences or just some scenarios that you imagine might happen.
Keep in mind that there is already considerable freedom in
how people write programs. What if we started getting flooded with
great programs written in French, or Spanish or Italian which
many of us couldn't understand. Should we mandate that for portability
all programs shall be written in English (or perhaps Esperanto)?
What if someone developed a loop macro that half the users loved and half
despised? Should we not include that macro in Common Lisp because people
might start using it and then write code that half the users can't read
without feeling ill?
Remember, the only thing that will change if this and the
READ-CASE-SENSITIVITY proposal pass is that the default case for symbol
names will be lower. Absolutely nothing else about your world or
the way you program need change.
If you want, we can privately correspond on these issues and then
send a summary of what we've concluded to this mailing list.
- john foderaro
∂17-Mar-89 1254 CL-Cleanup-mailer Issue: ADJUST-ARRAY-NOT-ADJUSTABLE (Version 8)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 17 Mar 89 12:54:39 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 559814; Fri 17-Mar-89 15:51:33 EST
Date: Fri, 17 Mar 89 15:51 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: ADJUST-ARRAY-NOT-ADJUSTABLE (Version 8)
To: Jon L White <jonl@lucid.com>
cc: cl-cleanup@sail.stanford.edu, X3J13@Sail.stanford.edu
In-Reply-To: <8903160732.AA11607@bhopal>
Message-ID: <19890317205125.6.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Wed, 15 Mar 89 23:32:47 PST
From: Jon L White <jonl@lucid.com>
Although I haven't had time to join the overly-lengthy discussion on this
matter, I did point out one particularly confusing direction -- that this
proposal to "fix" the function ADJUST-ARRAY has become a proposal to alter
the semantics of the type SIMPLE-ARRAY.
Adding the discussion of SIMPLE-ARRAY was at *+*YOUR*+* request, JonL.
There is !!NO!! change to the semantics, as I thought you had agreed in
the last message you sent on the topic. If now you're taking that back
and saying that you still think what this proposal says is a change to
the semantics, okay, but I have yet to figure out why you think that or
what you think is changed.
∂17-Mar-89 1257 X3J13-mailer Issue: ADJUST-ARRAY-NOT-ADJUSTABLE (Version 8)
Received: from Think.COM by SAIL.Stanford.EDU with TCP; 17 Mar 89 12:57:27 PST
Return-Path: <barmar@Think.COM>
Received: from OCCAM.THINK.COM by Think.COM; Fri, 17 Mar 89 15:52:50 EST
Date: Fri, 17 Mar 89 15:53 EST
From: Barry Margolin <barmar@Think.COM>
Subject: Issue: ADJUST-ARRAY-NOT-ADJUSTABLE (Version 8)
To: Jon L White <jonl@lucid.com>
Cc: cl-cleanup@sail.stanford.edu, X3J13@sail.stanford.edu
In-Reply-To: <8903160732.AA11607@bhopal>
Message-Id: <19890317205329.0.BARMAR@OCCAM.THINK.COM>
What happens in implementations that allow all arrays to be adjusted?
If you require that (typep x 'simple-array) implies (not
(adjustable-array-p x)), I see two possible resolutions: 1) such
implementations are not conforming; 2) the type SIMPLE-ARRAY is empty.
I find (1) distasteful, because non-adjustable arrays and the
SIMPLE-ARRAY type exist solely for the benefit of implementations that
need them, and this would require support of these concepts in
implementations that don't derive any benefit from them. I think (2)
makes the SIMPLE-ARRAY type pretty useless, since a portable program
can't expect anything to be of this type (FIXNUM had this problem until
we fixed it in Hawaii).
barmar
∂17-Mar-89 1327 CL-Cleanup-mailer DYNAMIC-EXTENT
Received: from REAGAN.AI.MIT.EDU by SAIL.Stanford.EDU with TCP; 17 Mar 89 13:27:36 PST
Received: from ISABEL-PERON.AI.MIT.EDU by REAGAN.AI.MIT.EDU via CHAOS with CHAOS-MAIL id 182401; Fri 17-Mar-89 16:22:14 EST
Date: Fri, 17 Mar 89 16:24 EST
From: Richard Mlynarik <Mly@AI.AI.MIT.EDU>
Subject: DYNAMIC-EXTENT
To: gls@think.com
cc: CL-Cleanup@sail.stanford.edu
In-Reply-To: <8903172021.AA09135@verdi.think.com>
Message-ID: <19890317212454.9.MLY@ISABEL-PERON.AI.MIT.EDU>
Date: Fri, 17 Mar 89 15:21:24 EST
From: Guy Steele <gls@think.com>
This is a genuine need. I suggest
(flet ((test (a b) ...))
(declare (dynamic-fextent test)) ;So pick a better name
(foo #'test))
A declaration in the body of the function feels preferable to me
as a user -- otherwise it is necessary to create a name for a function
simply to declare something about it. There may indeed be semantic
reasons to decide otherwise.
Another feature which I find sorely needed (and which nobody seems
to support) is a way to declare that the result of a form
has dynamic extent.
This proposal has problems. It is not enough to say
"foo has dynamic extent extent". [...]
Forget it. I was confused (probably by the fact that I use a lisp
implementation which has a dynamic-extent declaration within closures
but no general dynamic-extent declaration in the sense of the proposal.)
I should have written my sample macro as
(defmacro with-frob (thunk &body body)
(let ((tem (gensym)))
`(let ((,tem ,thunk))
(declare (dynamic-extent ,tem))
(let ((*frob-stack* (cons ,tem *frob-stack*)))
...))))
where I assume that the implementation knows to stack-allocate the `y' in
(let* ((foo 1)
(y (lambda () foo)))
(declare (dynamic-extent y))
... y ...)
∂17-Mar-89 1337 CL-Cleanup-mailer Issue: ADJUST-ARRAY-NOT-ADJUSTABLE (Version 9)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 17 Mar 89 13:37:36 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 559887; Fri 17-Mar-89 16:33:57 EST
Date: Fri, 17 Mar 89 16:33 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: ADJUST-ARRAY-NOT-ADJUSTABLE (Version 9)
To: Jon L White <jonl@lucid.com>, Masinter.pa@Xerox.com
cc: cl-cleanup@sail.stanford.edu
In-Reply-To: <8903160732.AA11607@bhopal>
Message-ID: <19890317213333.3.MOON@EUPHRATES.SCRC.Symbolics.COM>
Line-fold: No
This version is edited to reflect the changes I think JonL wants,
which I had thought were already in. I'll mail this to X3J13 to
supersede version 8, unless one of you asks me not to. That would
probably be more constructive than the intemperate message I already
sent.
Issue: ADJUST-ARRAY-NOT-ADJUSTABLE
References: ADJUST-ARRAY (p297), ADJUSTABLE-ARRAY-P (p293),
MAKE-ARRAY (pp286-289), simple arrays (p28, 289)
Category: CLARIFICATION
Edit history: 22-Apr-87, Version 1 by Pitman
15-Nov-88, Versions 2a,2b,2c by Pitman
02-Dec-88, Version 3 by Pitman
11-Jan-89, Version 4 by Pitman
16-Jan-89, Version 5, by Gabriel. Amended at the meeting to shorten.
23-Jan-89, Version 6, by Moon. Shorten without the bug introduced
by the amendment, add clarification of SIMPLE-ARRAY type.
15-Feb-89, Version 7, by Pitman. Minor changes per comments from
RPG and Dalton.
11-Mar-89, Version 8, by Pitman. Change category, add endorsements.
17-Mar-89, Version 9, by Moon, fix wording and examples to make it
clear that the semantics of simple-array is unchanged.
Problem Description:
The description of the :ADJUSTABLE option to MAKE-ARRAY on p288
says that ``the argument, if specified and not NIL, indicates that
it must be possible to alter the array's size dynamically after
it is created. This argument defaults to NIL.''
The description of the :ADJUSTABLE option does not say what
MAKE-ARRAY will do if the argument is unsupplied or explicitly NIL.
The description of ADJUSTABLE-ARRAY-P on p293 says that it is
true ``if the argument (which must be an array) is adjustable, and
otherwise false.'' However, the description of MAKE-ARRAY makes
it clear that this is not necessarily the same as asking if
the array was created with :ADJUSTABLE T. If ADJUSTABLE-ARRAY-P
returns NIL, you know that :ADJUSTABLE NIL was supplied (or no
:ADJUSTABLE option was supplied), but if ADJUSTABLE-ARRAY-P returns
T, then there is no information about whether :ADJUSTABLE was used.
The description of ADJUST-ARRAY on pp297-298 says that it is
``not permitted to call ADJUST-ARRAY on an array that was not
created with the :ADJUSTABLE option.'' This is inconsistent with
ADJUSTABLE-ARRAY-P.
A problem which comes up in practice is that some programmers
expect runtime error checking if they have done
(MAKE-ARRAY ... :ADJUSTABLE NIL) and they later try to adjust
the array using ADJUST-ARRAY.
The definition of the SIMPLE-ARRAY type and its subtypes needs
clarification of its relationship to adjustability.
Proposal (ADJUST-ARRAY-NOT-ADJUSTABLE:CLARIFY):
1. ADJUSTABLE-ARRAY-P is true of all arrays created with a true
:ADJUSTABLE option to MAKE-ARRAY. Whether ADJUSTABLE-ARRAY-P is
true of some other arrays is unspecified.
2. If MAKE-ARRAY is called with the :ADJUSTABLE, :FILL-POINTER,
and :DISPLACED-TO arguments each either unspecified or false, the
resulting array is a simple array. (This just repeats what CLtL
says on page 289, it's here to aid in understanding the next point.)
3. If MAKE-ARRAY is called with one or more of the :ADJUSTABLE,
:FILL-POINTER, or :DISPLACED-TO arguments true, whether the
resulting array is simple is unspecified.
4. ADJUST-ARRAY ``should signal'' an error if ADJUSTABLE-ARRAY-P
of its first argument is false. ADJUST-ARRAY must not signal an
`array not adjustable' error if ADJUSTABLE-ARRAY-P of its first
argument is true.
5. The value of ADJUSTABLE-ARRAY-P on a simple array is unspecified.
Note: ``should signal'' is taken from the new error terminology.
It means that in ``safe code'' (code compiled with highest safety)
an error must be signalled, but that in unsafe code (code not compiled
with highest safety), an error might or might not be signalled.
Clarifications and Logical Consequences:
a. Whether an array can be both simple and adjustable is unspecified.
b. There is no specified way to create an array for which ADJUSTABLE-ARRAY-P
definitely returns NIL.
c. There is no specified way to create an array that is non-simple.
d. This legitimizes ADJUSTABLE-ARRAY-P as an appropriate predicate to
determine whether ADJUST-ARRAY will reliably succeed.
e. If ADJUST-ARRAY is invoked on an array that was created without
supplying :ADJUSTABLE true, an `array not adjustable' error
``should be signalled'' unless ADJUSTABLE-ARRAY-P returns true on
that array (in which case it must not signal an `array not adjustable'
error).
f. There is no change to the meaning of the type SIMPLE-ARRAY, only
a clarification that a conforming program cannot assume that any
array is not simple.
Rationale:
This effectively makes the status quo explicit. This preserves the
raison d'etre of simple arrays, which is to provide a portable interface
to implementation-dependent specialized arrays that trade decreased
functionality for faster access.
A proposed alternative was to specify a way to create an array that is
guaranteed not to be simple. This would have required large changes
to some implementations and would be of little benefit to users.
Users need to know that certain arrays are simple, so they can put in
declarations and get higher performance, but users have no need to be
able to create arrays that are definitely non-simple (for lower
performance) or definitely non-adjustable (to cause errors).
Examples:
1. The following program is conforming. It is unspecified which branch
of the IF it follows.
(defun double (a)
(if (adjustable-array-p a)
(adjust-array a (* (length a) 2))
(let ((new (make-array (* (length a) 2))))
(replace new a :end1 (length a))
new)))
(double (make-array 30))
2. The following program is conforming. In no implementation is the
type declaration violated.
(let ((a (make-array 100)))
(declare (simple-array a))
(frob a))
3. The following program is non-conforming. The consequences of this
program are undefined because the type declaration is violated in some
valid implementations.
(let ((a (make-array 100 :adjustable t)))
(declare (simple-array a))
(frob a))
Current Practice:
Probably everyone is compatible with this proposal.
Symbolics Genera makes :ADJUSTABLE NIL arrays adjustable in most cases,
and ignores adjustability in deciding whether an array is simple,
and is compatible with this proposal.
Lucid, IIM, and Symbolics Cloe make :ADJUSTABLE NIL arrays non-adjustable
in all cases, and make all arrays non-simple unless the Common Lisp
language requires them to be simple, and are compatible with this proposal.
Cost to Implementors:
It's in principle possible that some implementation would have to change,
but in practice there are no known implementations that would have to change.
Cost to Users:
None. This is a fully compatible change from the user's standpoint.
Benefits:
Users would know what to expect.
Non-Benefits:
Users who expect adjusting arrays created with :ADJUSTABLE NIL to signal
an error would not get the desired error checking.
Aesthetics:
Most people believe the status quo is unaesthetic. Having an aspect of
the language explicitly unspecified is more aesthetic than having it
implicitly unspecified on account of vague or inconsistent documentation.
Discussion:
Pitman, Moon, Gabriel, and Steele support this amended proposal.
MACSYMA ran into portability problems due to the status quo.
If the issue had been documented, that would have helped.
Encouraging implementations that are able to at least make
(MAKE-ARRAY ... :ADJUSTABLE NIL) create non-adjustable arrays
where possible would help, too.
We considered proposals to incompatibly change this primitive in a
variety of ways, but the community was very split with strong proponents
and opponents of each alternate proposal.
The overriding concern driving this proposal is that Symbolics
has asserted that most of the other really interesting proposals would
likely involve a sizable cost to implementors (and their installed bases)
to implement what were judged by some as gratuitous changes from the
status quo.
Pitman wishes some of the other proposals were economically feasible to
pursue but reluctantly agrees that maintaining (and clearly documenting)
the status quo is probably the most reasonable avenue left to us.
∂17-Mar-89 1346 CL-Cleanup-mailer Issue: ADJUST-ARRAY-NOT-ADJUSTABLE (Version 6)
Received: from Think.COM by SAIL.Stanford.EDU with TCP; 17 Mar 89 13:45:46 PST
Received: from fafnir.think.com by Think.COM; Fri, 17 Mar 89 16:41:06 EST
Return-Path: <gls@Think.COM>
Received: from verdi.think.com by fafnir.think.com; Fri, 17 Mar 89 16:42:07 EST
Received: by verdi.think.com; Fri, 17 Mar 89 16:38:55 EST
Date: Fri, 17 Mar 89 16:38:55 EST
From: Guy Steele <gls@Think.COM>
Message-Id: <8903172138.AA09505@verdi.think.com>
To: jonl@lucid.com
Cc: gls@Think.COM, masinter.pa@xerox.com, cl-cleanup@sail.stanford.edu
In-Reply-To: Jon L White's message of Wed, 15 Mar 89 23:39:49 PST <8903160739.AA11617@bhopal>
Subject: Issue: ADJUST-ARRAY-NOT-ADJUSTABLE (Version 6)
Date: Wed, 15 Mar 89 23:39:49 PST
From: Jon L White <jonl@lucid.com>
re: I conclude that the strict interpretation may be preferred, but not for the
reasons Jonl has advanced! The liberal interpretation does *not* prevent
compilers for stock hardware from producing good code, and therefore the
code example does not support his claim to the contrary.
Guy, I fear that you have made an error of logic in analyzing my example.
You use the "strict" interpretation to conclude that the example is
incorrect code (as it should be!); but the whole point of the example is
to show that under the "liberal" interpretation, it's correctness depends
on the implementation rather than on a implementation-independent definition.
If you don't see this, then perhaps we should talk about it "off line".
I respectfully disagree with your assessment; I believe that you have
erred in analyzing my analysis. Specifically, I do *not* conclude
that the example is incorrect code. Let me quote further from my
message of Feb 28:
I argue that the program is correct under both interpretations....
Under the strict interpretation implementation (A) is incorrect by
definition. Under the liberal interpretation implementation (A) is
correct, and accomplishes a useful purpose. ...
According to my analysis, the correctness of the code does not depend
on the choice of strict or liberal interpretation; rather, the
correctness of implementation (A) depends on the choice of interpretation.
I conclude: (1) Under the strict interpretation only some
implementations are correct, but under the liberal interpretation many
more are correct. (2) You can get good code on stock hardware
regardless of the choice of interpretation.
Therefore unless some other argument can be advanced for the strict
interpretation, the liberal interpretation is to be preferred because it
invalidates fewer implementation strategies.
So there you have a concise summary of my argument that may make it
easier for you to find the hole in it (if any).
--Guy
∂17-Mar-89 1410 CL-Cleanup-mailer Re: Issue: EXPT-ZERO-ZERO (Version 1)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 17 Mar 89 14:10:35 PST
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 559948; Fri 17-Mar-89 17:07:44 EST
Date: Fri, 17 Mar 89 17:07 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: Issue: EXPT-ZERO-ZERO (Version 1)
To: masinter.pa@Xerox.COM
cc: KMP@symbolics.com, CL-Cleanup@sail.stanford.edu,
Cyphers@JASPER.SCRC.Symbolics.COM
In-Reply-To: <890316-211042-6708@Xerox>
Message-ID: <890317170725.7.KMP@BOBOLINK.SCRC.Symbolics.COM>
Date: 16 Mar 89 21:10 PST
From: masinter.pa@Xerox.COM
Kent, do you want to proceed with this one? I don't think it is necessary
or even a good idea. What do other programming languages do?
If you do, I think we should leave (EXPT 0 0) = 1 and (EXPT 0.0 0) = 1 and
only deal with (EXPT 0.0 0.0) and (EXPT 0 0.0).
Let's table it.
I asked a bunch of the people here about it and they didn't really buy
all the arguments advanced for why it was such a good idea to have 1
come out, but they didn't really care a lot since it was pretty easy to
special case zero before it ever got into EXPT in the first place.
Doesn't this fit into the ERRORS-IN-NUMBERS-CHAPTER spectrum?
If we were going to pursue it, I guess it could.
∂17-Mar-89 1541 CL-Cleanup-mailer Issue: ADJUST-ARRAY-NOT-ADJUSTABLE (Version 8)
Received: from Think.COM by SAIL.Stanford.EDU with TCP; 17 Mar 89 15:40:34 PST
Received: from fafnir.think.com by Think.COM; Fri, 17 Mar 89 16:23:16 EST
Return-Path: <gls@Think.COM>
Received: from verdi.think.com by fafnir.think.com; Fri, 17 Mar 89 16:24:05 EST
Received: by verdi.think.com; Fri, 17 Mar 89 16:20:53 EST
Date: Fri, 17 Mar 89 16:20:53 EST
From: Guy Steele <gls@Think.COM>
Message-Id: <8903172120.AA09400@verdi.think.com>
To: jonl@lucid.com
Cc: cl-cleanup@sail.stanford.edu, X3J13@sail.stanford.edu
In-Reply-To: Jon L White's message of Wed, 15 Mar 89 23:32:47 PST <8903160732.AA11607@bhopal>
Subject: Issue: ADJUST-ARRAY-NOT-ADJUSTABLE (Version 8)
Date: Wed, 15 Mar 89 23:32:47 PST
From: Jon L White <jonl@lucid.com>
...
Also, I note that all of the discussion on the Cl-cleanup list was by
persons other than the half-dozen or so maintainers of "stock hardware"
compilers. I personally spoke with three others (not including myself)
at Hawaii, and we all have identical requirements for the type SIMPLE-ARRAY,
and identical resolve that it must not be changed. Our compilers will
continue to offer this C-level optimization capability; the only
question is whether or not the CL1989 Standard will be cognizant of it.
I am very concerned about the stock hardware, but also very confused.
I understand that the stock-hardware implementors adamantly oppose
the proposed change, but I still have not seen a single convincing
example of why the proposed change would prevent them from accomplishing
the desired optimizations or why the proposed change would defeat
portability. I acknowledge that JonL has provided an example or two,
but I have not found them convincing. So either these examples are
wrong, or I am badly wedged; in either case I need further explanation.
--Guy
∂17-Mar-89 1555 CL-Cleanup-mailer Issue: ADJUST-ARRAY-NOT-ADJUSTABLE (Version 6)
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 17 Mar 89 15:55:19 PST
Received: from bhopal ([192.9.200.13]) by heavens-gate.lucid.com id AA02075g; Fri, 17 Mar 89 15:47:55 PST
Received: by bhopal id AA19349g; Fri, 17 Mar 89 15:50:11 PST
Date: Fri, 17 Mar 89 15:50:11 PST
From: Jon L White <jonl@lucid.com>
Message-Id: <8903172350.AA19349@bhopal>
To: gls@Think.COM
Cc: masinter.pa@xerox.com, cl-cleanup@sail.stanford.edu
In-Reply-To: Guy Steele's message of Fri, 17 Mar 89 16:38:55 EST <8903172138.AA09505@verdi.think.com>
Subject: Issue: ADJUST-ARRAY-NOT-ADJUSTABLE (Version 6)
re: Under the strict interpretation implementation (A) is incorrect by
definition. Under the liberal interpretation implementation (A) is
correct, and accomplishes a useful purpose. ...
Guy, I'm totally confused by your "analysis" now; the whole point of
the example is to show that portability is sacrificed under what you are
calling the "liberal" interpretation -- that altering the CLtL semantics
of SIMPLE-ARRAY makes it non portable. As I look back into your
previous msg, I see that you did say:
Now, the two implementations behave differently on the example, and that
is a cause for concern.
Also, your statement just quoted above shows the variations possible under
implementation (A) and (B), thus reiterating the non-portability question
I brought up. Thus you'll have to admit that my example showed *exactly*
what I claimed it did.
However, I disagree with your judgement -- that it is better to accept an
interpretation that allows more variation among implementations -- because
the variation you are thereby accommodating means that the type is no longer
portable. We may be stuck with that position, but I don't agree that it
is a good thing.
-- JonL --
∂17-Mar-89 1618 CL-Cleanup-mailer Issue: CONDITION-RESTARTS (Version 1)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 17 Mar 89 16:18:28 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 560081; Fri 17-Mar-89 19:15:40 EST
Date: Fri, 17 Mar 89 19:15 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: CONDITION-RESTARTS (Version 1)
To: Richard Mlynarik <Mly@AI.AI.MIT.EDU>, KMP@STONY-BROOK.SCRC.Symbolics.COM
cc: cl-cleanup@sail.stanford.edu
In-Reply-To: <19890317185835.8.MLY@ISABEL-PERON.AI.MIT.EDU>
Message-ID: <19890318001531.0.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Fri, 17 Mar 89 13:58 EST
From: Richard Mlynarik <Mly@AI.AI.MIT.EDU>
The proposal doesn't compensate for the mistake of having
disassociated restarts from context in the first place.
All restarts should have associated with them a real predicate
(not just a screwy wired-in (lambda (c) (eq c associated-condition)))
In general the applicability of a restart depends on the dynamic
environment in which it invoked as well as that in which it
was established.
You're absolutely right. In all the hoopla I had forgotten about this.
I think it's quite reasonable to have some convenient syntax for the
common case where the predicate is to test for a particular condition
object, but the underlying primitives should allow an arbitrary
predicate. RESTART-BIND needs to be enhanced with a :TEST argument,
which is a predicate function that COMPUTE-RESTARTS calls.
All restarting forms should require a condition argument (-not- NIL.)
I disagree with this, because it does make sense to restart a program
in response to some situation other than the signalling of a condition.
Why on earth do ABORT, USE-VALUE, etc still exist?
I don't know either.
The business about COPY-CONDITION is completely confused.
I agree with this. The argument against resignalling a condition
is wrong; there is no confusion of identity if a condition is signalled,
this results in some transfer of control, and then the same condition
object, representing the same situation that is still happening, is
signalled again. There is also no harm in a system keeping a particular
pre-created condition object around and using that same object every
time it signals a particular condition, so long as it keeps its restarts
straight. Since it is the program that signals a condition that
establishes restarts bound to that particular condition, it knows what
it is doing, and if it knows that it doesn't establish any restarts
that are associated to the particular condition object, it knows there
is no harm in reusing the condition object.
I don't care for the syntax, though it isn't worse than
that of the rest of the condition system.
I don't like the syntax in the version that got mailed to X3J13, which
I don't think was really ready for mailing. I had some alternate syntax
proposals, but I don't much like them either.
Here is what I would suggest doing to the proposal to make it ready
for X3J13:
1. Define that it is an error for SIGNAL to be called on a condition
more than once.
2. Introduce a function COPY-CONDITION
Remove items 1 and 2.
Add a :TEST argument to RESTART-BIND.
Add a :TEST argument to RESTART-CASE.
3. Introduce a macro WITH-CONDITION-RESTARTS
If we can't think of a better syntax for this, leave it out. It can
always be done, awkwardly, by first making the condition object and
binding it to a variable, then doing a RESTART-CASE with :TEST predicates
that check for the condition being that one and with the expression
just being a call to SIGNAL of that condition.
4. Extend COMPUTE-RESTARTS, FIND-RESTART, ABORT, CONTINUE, USE-VALUE,
and STORE-VALUE to permit an optional condition object as an argument.
OK.
5. Add two new macros SIGNAL-WITH-RESTARTS and ERROR-WITH-RESTARTS:
Same comment as #3.
6. Define that Common Lisp macros such as CHECK-TYPE, which are defined
to signal and to make restarts available, use the equivalent of
WITH-CONDITION-RESTARTS to associate the conditions they signal with
the defined restarts, so that users can make reliable tests not only
for the restarts being available, but also for them being available
for the right reasons.
OK (except don't use the name WITH-CONDITION-RESTARTS).
∂17-Mar-89 1627 CL-Cleanup-mailer Issue: PACKAGE-FUNCTION-CONSISTENCY (version 4)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 17 Mar 89 16:26:59 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 560089; Fri 17-Mar-89 19:24:33 EST
Date: Fri, 17 Mar 89 19:24 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: PACKAGE-FUNCTION-CONSISTENCY (version 4)
To: CL-Cleanup@sail.stanford.edu
In-Reply-To: <890317-102812-1247@Xerox>
Message-ID: <19890318002424.2.MOON@EUPHRATES.SCRC.Symbolics.COM>
I think this one is more correct than the one Larry mailed
to X3J13, in its reflection of the amendments voted in at
the last meeting. I'll mail it to X3J13 if no one disagrees.
!
Issue: PACKAGE-FUNCTION-CONSISTENCY
References: 11.7 Package System Functions and Variables (pp182-188)
Category: CLARIFICATION/CHANGE
Edit history: 21-Oct-88, Version 1 by Pitman
12-Jan-89, Version 2 by Masinter (add MORE-PERMISSIVE option)
17-Mar-89, Version 3, by Masinter, MORE-PERMISSIVE as
amended & adopted at Jan 89 X3j13
17-Mar-89, Version 4, by Moon, correct amended wording
Problem Description:
CLtL is vague about whether either or both of package or package name
are permissible in some cases.
Proposal (PACKAGE-FUNCTION-CONSISTENCY:MORE-PERMISSIVE):
Clarify that it is permissible to pass either a package object
or a package name (symbol or string) in the following situations:
- the :USE argument to MAKE-PACKAGE or IN-PACKAGE
- the first argument to IN-PACKAGE, FIND-PACKAGE, RENAME-PACKAGE
or DELETE-PACKAGE
- the second argument to INTERN, FIND-SYMBOL, UNINTERN
- the second argument to EXPORT, UNEXPORT, IMPORT,
SHADOWING-IMPORT, and SHADOW
- the first argument (or a member of the list which is the first
argument) to USE-PACKAGE or UNUSE-PACKAGE.
- all package-name arguments in DEFPACKAGE except for the name and
nicknames of the package being defined.
- the first argument to PACKAGE-NAME, PACKAGE-NICKNAMES,
PACKAGE-USE-LIST, or PACKAGE-USED-BY-LIST
- the PACKAGE argument to DO-SYMBOLS.
- the PACKAGE argument to DO-EXTERNAL-SYMBOLS.
- the PACKAGE argument to DO-ALL-SYMBOLS.
If FIND-PACKAGE is given a package object as an argument, it simply
returns it.
Clarify that the function MAKE-PACKAGE permits only a package name
as an argument since it does not make sense to create an existing
package.
Clarify that package nicknames must always be expressed as package
names (symbols or strings) and may never be actual package objects.
In the list above, IN-PACKAGE may be changed to SELECT-PACKAGE
if IN-PACKAGE-FUNCTIONALITY:NEW-MACRO passes.
Examples:
(INTERN "FOO" "KEYWORD") => :FOO
(DEFVAR *FOO-PACKAGE* (MAKE-PACKAGE "FOO"))
(RENAME-PACKAGE "FOO" "FOO0")
(PACKAGE-NAME *FOO-PACKAGE*) => "FOO0"
(PACKAGE-NAME "SYS") might return "SYSTEM".
Rationale:
This makes things more consistent.
It also adds a generally useful capability.
Current Practice:
Symbolics Genera & Lucid permit strings as package names.
Symbolics Cloe does not permit strings as package names.
In Lucid FIND-PACKAGE and IN-PACKAGE require names.
Cost to Implementors:
Small.
Cost to Users:
None. This change is upward compatible.
Cost of Non-Adoption:
Implementations would continue to vary gratuitously, leaving a potential
for portability problems.
Benefits:
The cost of non-adoption is avoided.
Aesthetics:
This makes things more regular, and so presumably more aesthetic.
Discussion:
Pitman ran across this problem while trying to port Macsyma to various
implementations. Discussion with other maintainers of portable programs
shows this is a common source of aggravation in portable code.
It would be possible to say that MAKE-PACKAGE took package objects as
arguments and just returned that package. That might have limited
usefulness on rare occasions, but mostly seemed too far out in left
field to bother suggesting it.
∂17-Mar-89 1600 X3J13-mailer Issue: ADJUST-ARRAY-NOT-ADJUSTABLE (Version 8)
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 17 Mar 89 16:00:33 PST
Received: from bhopal ([192.9.200.13]) by heavens-gate.lucid.com id AA02088g; Fri, 17 Mar 89 15:53:13 PST
Received: by bhopal id AA19366g; Fri, 17 Mar 89 15:55:29 PST
Date: Fri, 17 Mar 89 15:55:29 PST
From: Jon L White <jonl@lucid.com>
Message-Id: <8903172355.AA19366@bhopal>
To: Moon@STONY-BROOK.SCRC.Symbolics.COM
Cc: cl-cleanup@sail.stanford.edu, X3J13@Sail.stanford.edu
In-Reply-To: David A. Moon's message of Fri, 17 Mar 89 15:51 EST <19890317205125.6.MOON@EUPHRATES.SCRC.Symbolics.COM>
Subject: Issue: ADJUST-ARRAY-NOT-ADJUSTABLE (Version 8)
re: Adding the discussion of SIMPLE-ARRAY was at *+*YOUR*+* request, JonL.
Sorry, Dave, I only ever made a request to add precisely the one statement
that you have already now added -- that the proposal *does not* alter
the CLtL semantics of SIMPLE-ARRAY. What I critiqued were statements
of the proposal that under reasonable interpretation could be taken to
mean that the CLtL p.28 definition of SIMPLE-ARRAY is being abrogated.
At any rate, thanks for the one-line addition.
-- JonL --
∂17-Mar-89 1613 X3J13-mailer Issue: ADJUST-ARRAY-NOT-ADJUSTABLE (Version 8)
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 17 Mar 89 16:13:52 PST
Received: from bhopal ([192.9.200.13]) by heavens-gate.lucid.com id AA02119g; Fri, 17 Mar 89 16:06:33 PST
Received: by bhopal id AA19436g; Fri, 17 Mar 89 16:08:50 PST
Date: Fri, 17 Mar 89 16:08:50 PST
From: Jon L White <jonl@lucid.com>
Message-Id: <8903180008.AA19436@bhopal>
To: barmar@Think.COM
Cc: cl-cleanup@sail.stanford.edu, X3J13@sail.stanford.edu
In-Reply-To: Barry Margolin's message of Fri, 17 Mar 89 15:53 EST <19890317205329.0.BARMAR@OCCAM.THINK.COM>
Subject: Issue: ADJUST-ARRAY-NOT-ADJUSTABLE (Version 8)
re: I find (1) distasteful, because non-adjustable arrays and the
SIMPLE-ARRAY type exist solely for the benefit of implementations that
need them, and this would require support of these concepts in
implementations that don't derive any benefit from them.
Barry, SIMPLE-ARRAY is certainly not the only concept in CLtL that exists
"solely for the benefit of implementations that [can really use it]". I
know that numerous array capabilities are present but not very useful
in Lucid Common Lisp primarily for compatiblity with Lisp Machine stuff.
That's the price to pay for portability. It just may be that we will have
to confess that we didn't succeed at portability in some areas of CL.
-- JonL --
∂17-Mar-89 1657 CL-Cleanup-mailer Issue: FIXNUM-NON-PORTABLE, v.5
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 17 Mar 89 16:57:14 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 560137; Fri 17-Mar-89 19:54:04 EST
Date: Fri, 17 Mar 89 19:53 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: FIXNUM-NON-PORTABLE, v.5
To: masinter.pa@Xerox.COM
cc: cl-cleanup@sail.stanford.edu
In-Reply-To: <890316-220933-6804@Xerox>
Message-ID: <19890318005344.5.MOON@EUPHRATES.SCRC.Symbolics.COM>
Line-fold: No
Date: 16 Mar 89 21:51 PST
From: masinter.pa@Xerox.COM
This is my rewrite to capture the 'intent' of the amendment
at the January X3J13. I say 'intent' because the relation
between MOST-POSITIVE-FIXNUM (which is an inclusive bound)
and ARRAY-DIMENSION-LIMIT (which is an exclusive bound) is not
> but rather (>= MOST-POSITIVE-FIXNUM (1- ARRAY-DIMENSION-LIMIT)).
No, the amendment was (<= ARRAY-DIMENSION-LIMIT MOST-POSITIVE-FIXNUM),
and this was not a mistake nor an off-by-one error. What you've
put in the proposal here is incorrect, I think. I think it was
fully intended that not only every valid array index and every
array dimension, but also array-dimension-limit itself would be
a fixnum. Someone might want to write an arithmetic iteration
whose upper bound was array-dimension-limit.
∂17-Mar-89 1656 X3J13-mailer Issue: ADJUST-ARRAY-NOT-ADJUSTABLE (Version 8)
Received: from Think.COM by SAIL.Stanford.EDU with TCP; 17 Mar 89 16:56:32 PST
Return-Path: <barmar@Think.COM>
Received: from OCCAM.THINK.COM by Think.COM; Fri, 17 Mar 89 19:52:28 EST
Date: Fri, 17 Mar 89 19:53 EST
From: Barry Margolin <barmar@Think.COM>
Subject: Issue: ADJUST-ARRAY-NOT-ADJUSTABLE (Version 8)
To: Jon L White <jonl@lucid.com>
Cc: cl-cleanup@sail.stanford.edu, X3J13@sail.stanford.edu
In-Reply-To: <8903180008.AA19436@bhopal>
Message-Id: <19890318005322.4.BARMAR@OCCAM.THINK.COM>
Date: Fri, 17 Mar 89 16:08:50 PST
From: Jon L White <jonl@lucid.com>
re: I find (1) distasteful, because non-adjustable arrays and the
SIMPLE-ARRAY type exist solely for the benefit of implementations that
need them, and this would require support of these concepts in
implementations that don't derive any benefit from them.
Barry, SIMPLE-ARRAY is certainly not the only concept in CLtL that exists
"solely for the benefit of implementations that [can really use it]". I
know that numerous array capabilities are present but not very useful
in Lucid Common Lisp primarily for compatiblity with Lisp Machine stuff.
That's the price to pay for portability. It just may be that we will have
to confess that we didn't succeed at portability in some areas of CL.
-- JonL --
The general rule has been that implementations that don't need (or don't
provide) these types of optimizations can safely ignore the language
features that support them. Some implementations can optimize array
access by knowing that the array can't be adjusted; other
implementations should not be required to remember this information if
they don't need it. Quoting from CLtL: "features that are useful only
on certain 'ordinary' or 'commercial' processors are avoided or made
optional."
Any feature of the language that provides access to facets of the
implementation allows somewhat non-portable code, meaning that it is
possible to write conforming code that produces different results in
different implementations. The simple program (PROGN
MOST-POSITIVE-FIXNUM) is conforming but produces many different results,
although the program (TYPEP MOST-POSITIVE-FIXNUM 'FIXNUM) is guaranteed
to return T in all conforming implementations. To paraphrase Moon, it
would be wonderful if all conforming programs were portable, but that's
unrealistic (it would be like expecting the grammar of a language to
only permit sensible sentences to be formed -- I suspect Godel's
Incompleteness Theorem comes into play here, pointing out that if the
grammar allows you to say everything you'd want to say, it must also
include some nonsense). The best I think we can do is provide enough
tools in the language to allow programs to detect implementation
differences and deal with them.
One thing that would help me is if you would post an example of code
that you feel is affected by this issue. I think you described such
things to me in words at the last meeting, but I (like GLS) am having a
hard time figuring out precisely what the problem is (I had the same
difficulty with the FIXNUM stuff that started the moby flame session in
the car on the way to the Japanese restaurant).
barmar
∂17-Mar-89 1839 CL-Cleanup-mailer Re: Issue: FIXNUM-NON-PORTABLE, v.5
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 17 Mar 89 18:39:40 PST
Received: from Semillon.ms by ArpaGateway.ms ; 17 MAR 89 18:09:23 PST
Date: 17 Mar 89 18:02 PST
From: masinter.pa@Xerox.COM
Subject: Re: Issue: FIXNUM-NON-PORTABLE, v.5
In-reply-to: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>'s message
of Fri, 17 Mar 89 19:53 EST
To: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
cc: masinter.pa@Xerox.COM, cl-cleanup@sail.stanford.edu
Message-ID: <890317-180923-2962@Xerox>
OK, I'll fix it. Thanks.
Larry
∂17-Mar-89 1949 CL-Cleanup-mailer Re: Issue: CONDITION-RESTARTS (Version 1)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 17 Mar 89 19:49:18 PST
Received: from Semillon.ms by ArpaGateway.ms ; 17 MAR 89 19:24:08 PST
Date: 17 Mar 89 19:23 PST
From: masinter.pa@Xerox.COM
Subject: Re: Issue: CONDITION-RESTARTS (Version 1)
In-reply-to: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>'s message
of Fri, 17 Mar 89 19:15 EST
To: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
cc: cl-cleanup@sail.stanford.edu, Mly@AI.AI.MIT.EDU
Message-ID: <890317-192408-3127@Xerox>
I was mailing the "best draft" of all issues we want to discuss to X3J13 in
the hopes that, even if there are new proposals brought to the meeting,
they won't get the "two week" rule applied if they are minor adjustments.
Now that its less than two-weeks until the end of the meeting, I think I'll
stop trying, if the issues aren't ready.
∂17-Mar-89 2009 CL-Cleanup-mailer Issue: DEFMACRO-LAMBDA-LIST, v.2
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 17 Mar 89 20:05:27 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 17 MAR 89 19:50:34 PST
Date: 17 Mar 89 19:44 PST
From: masinter.pa@Xerox.COM
to: cl-cleanup@sail.stanford.edu
Subject: Issue: DEFMACRO-LAMBDA-LIST, v.2
Message-ID: <890317-195034-3172@Xerox>
I didn't mean to do this, but I started. It took more time
because the last writeup really presumed that &WHOLE wasn't
allowed at inner levels, so I had to mung it to change
that assumption.
However, I really think this is just a clarification of
'current practice'; I'd be suprised to find an implementation
didn't really already conform to this.
So I rewrote the cost/benefit section; do you know any
counterexamples?
!
Issue: DEFMACRO-LAMBDA-LIST
Forum: Cleanup
References: 8.1 Macro Definition (CLtL pp144-151),
Issue DESTRUCTURING-BIND
Category: CLARIFICATION/CHANGE
Edit history: 30-Jan-89, Version 1 by Pitman
17-Mar-89, Version 2 by Masinter
Problem Description:
The description of the DEFMACRO lambda list currently contains some
mis-statements and leaves some ambiguities:
1. Can &BODY, &WHOLE, and &ENVIRONMENT appear at recursive levels of the
DEFMACRO lambda list?
The description of &WHOLE (p145) specifies that &WHOLE must occur ``first
in the lambda list,'' but the description of a lambda list says that
``a lambda may [recursively] appear in place of the parameter name.''
Consequently, the question arises whether &WHOLE should be permitted to
be a synonym for &REST at inner levels of a DEFMACRO lambda list.
The descriptions of &BODY and &ENVIRONMENT do not contain syntactic
restrictions on where they may appear.
2. Does using &WHOLE affect the pattern of arguments permitted by DEFMACRO.
Proposal (DEFMACRO-LAMBDA-LIST:TIGHTEN-DESCRIPTION):
1. a. Specify that &BODY may appear at any level of a DEFMACRO lambda list.
b. Specify that &WHOLE may only appear at any level of a DEFMACRO
lambda list. At inner levels, the &WHOLE variable is bound to
the corresponding part of the argument, as with &REST, but
unlike &REST, other arguments are also allowed.
c. Specify that &ENVIRONMENT may only appear at the top level of a
DEFMACRO lambda list.
2. Clarify that using &WHOLE does not affect the pattern of arguments
specified by DEFMACRO.
Examples:
1. (DEFMACRO DM1A (&WHOLE FORM A B) ...) is defined.
(DEFMACRO DM1B (A (&WHOLE B C &OPTIONAL D) E) ...) is defined.
It allows simultaneousaccess to the THIRD of the whole
form as B and to the destructuring of that list into
C and D.
(DEFMACRO DM1C (A B &ENVIRONMENT ENV) ...) is defined.
(DEFMACRO DM1D (A (B &ENVIRONMENT ENV) C) ...) is undefined.
(DEFMACRO DM1E (A B &BODY X) ...) is defined.
(DEFMACRO DM1F (A (B &BODY X) C) ...) is defined.
2. (DEFMACRO DM2A (&WHOLE X) `',X)
(MACROEXPAND '(DM2A)) => (QUOTE (DM2A))
(MACROEXPAND '(DM2A A)) is an error.
(DEFMACRO DM2B (&WHOLE X A &OPTIONAL B) `'(,X ,A ,B))
(MACROEXPAND '(DM2B)) is an error.
(MACROEXPAND '(DM2B Q)) => (QUOTE ((DM2B Q) Q NIL))
(MACROEXPAND '(DM2B Q R)) => (QUOTE ((DM2B Q R) Q R))
(MACROEXPAND '(DM2B Q R S)) is an error.
Rationale:
1. a. An example on p151 makes it clear that this was the intent.
b. There's no cogent reason to forbid &WHOLE at inner levels.
The example on p.150 uses &WHOLE in a non-top-level position.
This simplifies the implementation of DEFMACRO if we introduce a
DESTRUCTURING-BIND which does not understand &ENVIRONMENT.
c. The environment is never different at top level than embedded.
Permitting &ENVIRONMENT to occur embedded would only encourage
the misconception that there was a potential difference.
This simplifies the implementation of DEFMACRO if we introduce a
DESTRUCTURING-BIND which does not understand &ENVIRONMENT.
2. This allows useful syntax checking.
One can always trivially write
(DEFMACRO ... (&WHOLE FORM &REST IGNORE) ...)
to get around the error checking this forces.
Current Practice:
1. a. Symbolics Genera permits &BODY at any level. This is compatible.
b. Symbolics Genera seems to permit &WHOLE at any level. When embedded,
it is treated as a synonym for &REST.
c. Symbolics Genera does not permit &ENVIRONMENT except at top level.
This is compatible.
2. Symbolics Genera has this behavior when &WHOLE appears at top level,
but not at recursive levels (where &WHOLE is treated as a synonym for
&REST).
Cost to Implementors:
This seems to be what CLtL intended and what most implementations
perform.
Cost to Users:
We think this is possibly (probably) upward compatible with most
current practice.
Cost of Non-Adoption:
Some fuzzy places in DEFMACRO continue to exist.
It's harder to introduce DESTRUCTURING-BIND because describing its relation
to DEFMACRO is difficult.
Benefits:
The language is a little tighter.
Aesthetics:
Negligible impact.
Discussion:
Part 2 of this issue came up during the discussion of DOTTED-MACRO-FORMS
but was not pursued until now.
Pitman supports these clarifications.
A previous version disallowed &WHOLE at inner levels, because
of the mistaken impression that &WHOLE was equivalent to &REST.
However, additional arguments are not allowed after &REST,
while they are for &WHOLE.
∂17-Mar-89 2126 CL-Cleanup-mailer New issue: WITH-OPEN-FILE-DOES-NOT-EXIST
Received: from Sun.COM by SAIL.Stanford.EDU with TCP; 17 Mar 89 21:25:40 PST
Received: from snail.Sun.COM (snail.Corp.Sun.COM) by Sun.COM (4.1/SMI-4.0)
id AA23966; Fri, 17 Mar 89 21:26:15 PST
Received: from denali.sun.com by snail.Sun.COM (4.1/SMI-4.1)
id AA08587; Fri, 17 Mar 89 21:22:28 PST
Received: from localhost by denali.sun.com (3.2/SMI-3.2)
id AA21223; Fri, 17 Mar 89 21:25:44 PST
Message-Id: <8903180525.AA21223@denali.sun.com>
To: cl-cleanup@sail.stanford.edu
Subject: New issue: WITH-OPEN-FILE-DOES-NOT-EXIST
Date: Fri, 17 Mar 89 21:25:42 PST
From: peck@Sun.COM
Really a request for an editorial change, so users will know what
to expect. A user actually reported this as a bug...
Unless someone believes that STREAM-IS-NIL is wrong, this could just
be forwarded to editorial.
Issue: WITH-OPEN-FILE-DOES-NOT-EXIST
References: CLtL page 422
Category: Clarify
Edit history: 17-Mar-89, Version 1
Problem description:
The documentation for WITH-OPEN-FILE (p 422) says:
"WITH-OPEN-FILE evaluates the Forms of the body (an implict PROGN)
with the variable Stream bound to a stream that reads or writes the
file named by the value of Filename. The options are evaluated and
used as keyword arguments to the function OPEN."
It is not clear what to do when there is no stream
"that reads or writes the file" named by Filename.
Is the body evaluated? What is Stream bound to?
Proposal: WITH-OPEN-FILE-DOES-NOT-EXIST:DONT-EVALUATE
If the result of OPEN does not return a stream (eg returns NIL)
Then the body of WITH-OPEN-FILE is not evaluated, NIL is returned.
Rationale:
The contract that "the body is evaluated with ... bound to a stream"
is maintained in the sense of a vacuous evalation.
The alternatives are:
To let the stream variable be bound to NIL (unintuitive and dangerous).
If users want to Signal-An-Error in this case, they can use
:if-does-not-exist :error
The test for (STREAMP Stream) is probably done anyway,
since the UNWIND-PROTECT cleanup form can't call CLOSE on NIL.
Proposal: WITH-OPEN-FILE-DOES-NOT-EXIST:STREAM-IS-NIL
Clarify the documentation to explain that:
Stream is bound to the value returned by OPEN.
Users of :if-does-not-exist NIL should check for a valid stream.
Rationale:
This simple to implement, no extra testing is done.
Users who use :if-does-not-exist NIL can wrap their body forms
with (when (STREAMP Stream) ...)
Examples:
1. (WITH-OPEN-FILE (foo "no-such-file" :IF-DOES-NOT-EXIST nil)
(READ foo) t)
DONT-EVALUATE: => NIL, no I/O is done, do not read from *standard-input*
STREAM-IS-NIL: => T, reads from *standard-input*
2. (WITH-OPEN-FILE (foo "/no-dir" :direction :output :IF-DOES-NOT-EXIST nil)
(format foo t) t)
DONT-EVALUATE: => NIL, no string is created.
STREAM-IS-NIL: => T, creates a string and writes to it.
Current practice:
Symbolics and Lucid apparently implement STREAM-IS-NIL.
Cost to Implementors:
STREAM-IS-NIL: no cost.
DONT-EVALUATE:
Trivial? to test for :if-does-not-exist NIL and supply a
test for (STREAMP Stream) in that case [or in every case].
Cost to Users:
DONT-EVALUATE: System tests for (STREAMP Stream), possibly extraneously.
STREAM-IS-NIL: User must write a test for (STREAMP Stream).
Probably no portable code uses :if-does-not-exist NIL without
testing explicitly for (STREAMP Stream).
Cost of non-adoption:
The current situation is non-intuitive and/or confusing.
Benefits:
Users would know if the STREAMP test has been done or whether
they must supply it.
Esthetics:
Discussion:
∂17-Mar-89 2128 CL-Cleanup-mailer Re: DEFAULT-CASE
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 17 Mar 89 21:28:18 PST
Received: from Semillon.ms by ArpaGateway.ms ; 17 MAR 89 21:25:52 PST
Date: 17 Mar 89 21:25 PST
From: masinter.pa@Xerox.COM
Subject: Re: DEFAULT-CASE
In-reply-to: franz!frisky!jkf@ucbarpa.Berkeley.EDU (John Foderaro)'s
message of Thu, 16 Mar 89 12:21:57 PST
To: franz!frisky!jkf@ucbarpa.Berkeley.EDU (John Foderaro)
cc: CL-Cleanup@sail.stanford.EDU
Message-ID: <890317-212552-3367@Xerox>
I'm going to unilaterally declare that this issue is not a "cleanup".
If you or someone else wants to raise it at X3J13, you should request
time on the agenda to bring it up and discuss it.
∂17-Mar-89 2140 CL-Cleanup-mailer Issue: TYPE-OF-UNDERCONSTRAINED, v.5
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 17 Mar 89 21:40:20 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 560258; 18 Mar 89 00:37:50 EST
Date: Sat, 18 Mar 89 00:37 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: TYPE-OF-UNDERCONSTRAINED, v.5
To: cl-cleanup@sail.stanford.edu
In-Reply-To: <890316-175451-6328@Xerox>
Message-ID: <19890318053740.8.MOON@EUPHRATES.SCRC.Symbolics.COM>
This version looks okay as far as making the amendments goes, but
in reading it over I noticed some problems that are really with
the original proposal. If we have to go over this issue again,
I think we should consider fixing these problems too.
(1) Why are the following types omitted from part (a), the list
of types for which TYPE-OF must be specific:
BIT-VECTOR NULL SEQUENCE
I constructed this list from 88-002R pp.1-16 and 1-17, and from the
specifications of which types are exhaustive partitions, I didn't
make it up randomly.
(2) Why are the following types omitted from part (a), the list
of types for which TYPE-OF must be specific:
BIGNUM FIXNUM KEYWORD STANDARD-CHAR STRING-CHAR
(replace STRING-CHAR with BASE-CHARACTER if that proposal passes)
Unlike the first list, I constructed this one randomly out of my head.
It's all the standard "interesting" subtypes of the types that are
already listed in part (a), excluding the simple array subtypes.
(3) The statement "For all objects for which CLASS-OF returns a class
with a proper name, TYPE-OF returns that proper name." is questionable.
For example, part (a) requires that TYPE-OF a single-float must return
SINGLE-FLOAT or a subtype of it, but 88-002R requires that CLASS-OF a
single-float be a class whose proper name is FLOAT, or an implementation
dependent subclass of that class. This proposal will force
implementations to create such subclasses, which should be done on its
own merits, not through the back door. Another example is that for
arrays, TYPE-OF will not be able to return a list that encodes the
element-type and dimensions, unless there are implementation dependent
classes corresponding to every such type specifier. There is a really
baroque way to get around this, which is to define an implementation
dependent subclass of ARRAY that has a non-null name that is not its
proper name; this slips through a loophole in the proposal and allows
TYPE-OF to return any subtype of ARRAY. I claim that loophole is a
bug too.
To fix these bugs, I suggest removing the four paragraphs that contain
the three references to CLASS-OF, and replacing them with:
(d) The type returned by TYPE-OF is always a subtype of the class
returned by CLASS-OF, and is a subtype that the implementation's
SUBTYPEP can recognize.
(e) For objects of metaclass STRUCTURE-CLASS or STANDARD-CLASS,
TYPE-OF returns the proper name of the class returned by CLASS-OF
if it has a proper name, and otherwise returns the class itself.
In particular, for objects created by the "constructor" function
of a structure defined with DEFSTRUCT without a :TYPE option,
TYPE-OF will return the structure name.
(4) I suggest modifying part (c) to exclude SATISFIES, AND, OR,
NOT, and VALUES in addition to MEMBER and T. Of course part (c)
is a very weak restriction, since TYPE-OF is perfectly free to
return a symbol that is DEFTYPEd to one of these type specifiers,
as long as the other requirements are met.
∂17-Mar-89 2153 CL-Cleanup-mailer Re: Issue: READ-CASE-SENSITIVITY (Version 1)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 17 Mar 89 21:53:22 PST
Received: from Semillon.ms by ArpaGateway.ms ; 17 MAR 89 21:50:37 PST
Date: 17 Mar 89 21:50 PST
From: masinter.pa@Xerox.COM
Subject: Re: Issue: READ-CASE-SENSITIVITY (Version 1)
In-reply-to: Jeff Dalton <jeff%aiai.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK>'s
message of Wed, 15 Mar 89 15:57:02 GMT
To: Jeff Dalton <jeff%aiai.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK>
cc: Kent M Pitman <KMP@scrc-stony-brook.arpa>, Masinter.PA@Xerox.COM,
CL-Cleanup@sail.stanford.edu
Message-ID: <890317-215037-3421@Xerox>
I think the issue is the handling of the printer. PRINT, when
*PRINT-ESCAPE* is set. needs to look at the case of the readtable to know
how to print out things so they will read in correctly.
Take symbols with symbol-name "Frob" and "FROB" respectively.
print print
Symbol-name case-sensitive case-insensitive
Frob Frob |Frob|
FROB FROB frob, Frob, or FROB
(depending on *PRINT-CASE*)
I think this is a "cleanup" issue, since it is a minor extension
to the feature of readtables and is upward compatible.
∂17-Mar-89 2223 CL-Cleanup-mailer Re: Issue: TYPE-OF-UNDERCONSTRAINED, v.5
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 17 Mar 89 22:23:00 PST
Received: from Semillon.ms by ArpaGateway.ms ; 17 MAR 89 22:14:13 PST
Date: 17 Mar 89 22:09 PST
From: masinter.pa@Xerox.COM
Subject: Re: Issue: TYPE-OF-UNDERCONSTRAINED, v.5
In-reply-to: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>'s message
of Sat, 18 Mar 89 00:37 EST
To: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
cc: cl-cleanup@sail.stanford.edu
Message-ID: <890317-221413-3463@Xerox>
I think BIT-VECTOR might have been an omission.
NULL was left out because it seemed silly and at odds with current practice
to require that (TYPE-OF 'NIL) = NULL. However, if (CLASS-OF 'NIL) is the
special NULL class, then we would have to reconsider.
SEQUENCE was left out because it is an 'abstract' class and is (as far as
the standard is concerned) exhaustively partitioned by VECTOR and LIST
which are already "lower bounds" of TYPE-OF.
BIGNUM and FIXNUM were left out because their division was implementation
dependent.
KEYWORD was left out because under odd circumstances it is possible to
dynamically change the 'type' (e.g., by UNINTERN).
STANDARD-CHAR and STRING-CHAR were left out for the same reasons they
aren't built-in classes.
- - - - -
I like your proposed fixes to the CLASS-OF wording.
- - - - -
About part (c): the restriction on T is meaningless, since the CLASS-OF
restriction dominates it. The restriction on MEMBER is OK, just to keep
TYPE-OF from being the silly definition that (type-of x) = `(member ,x). I
think we're running out of good reasons to leave out SATISFIES, AND, OR,
NOT, and VALUES; they're probably no more useful, but we're probably
overspecifying for no good reason.
However, I'll be happy to go along with whatever you feel is right on this
one...
∂17-Mar-89 2235 CL-Cleanup-mailer Issue: PRETTY-PRINT-INTERFACE (version 3)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 17 Mar 89 22:35:17 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 560283; Sat 18-Mar-89 01:32:31 EST
Date: Sat, 18 Mar 89 01:32 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: PRETTY-PRINT-INTERFACE (version 3)
To: Guy Steele <gls@Think.COM>
cc: cl-cleanup@sail.stanford.edu
In-Reply-To: <8903152049.AA03416@verdi.think.com>
Message-ID: <19890318063223.0.MOON@EUPHRATES.SCRC.Symbolics.COM>
In general I like this. Certainly I like the idea of having a
standardized interface for extending the pretty-printer, and I believe
that this particular pretty-printer is based on a good underlying
theory, certainly the best theory that I have seen. However, I don't
think this is ready to go into the standard in its current form. Some
of these comments are on the programmer interface, others are just on
the way the proposal is presented.
I could not find any specification of the units of measurement for
*PRINT-RIGHT-MARGIN*, *DEFAULT-RIGHT-MARGIN*, *PRINT-MISER-WIDTH*,
indentation, and tabulation. It's not even clear that margins,
indentation, and tabulation can't be measured in three different
units. Analysis of the examples suggests that the units are
assumed to be characters and all characters are assumed to be the
same width. This is not an implementation-independent assumption.
In any case the proposal has to be specific about the units. I
would prefer something that seamlessly accomodates variable-width
characters, but don't have enough experience with pretty-printers
to propose anything myself.
I would like to be able to vote on the FORMAT-based interface and
the functional interface separately.
I would like to see the DEFINE-PRINT-DISPATCH mechanism recast in terms
of DEFMETHOD and a PRETTY-PRINT-OBJECT generic function. If DEFMETHOD
is deficient and unable to provide all the necessary features, I think
we need to know that before it's too late to amend CLOS. I don't see
any problems myself, other than the need to replace the funny extension
to the CONS type-specifier with passing of the CAR of the CONS as a
separate argument so an EQL parameter specializer can be used.
I'd like to suggest some improvements to the syntax of
WITHIN-LOGICAL-BLOCK, based on Symbolics experience with similar macros:
Instead of separate :STREAM and :VAR keywords, it works better to have
only a :STREAM keyword, whose value must be a symbol. This symbol
is evaluated to get the stream, and also is bound around the body to
a (possibly new) stream. This simplifies the syntax and avoids the
risk of accidentally writing to the wrong stream.
Defaulting to *STANDARD-OUTPUT* and handling T and NIL is correct here
(:STREAM NIL means *STANDARD-OUTPUT* is the variable that gets bound.)
Since the :ARG argument appears to be mandatory, it should be a
required argument preceding the keyword arguments. This would also
eliminate the meaningless keyword name for this argument.
It would be nice if the :PREFIX, :PER-LINE-PREFIX, and :SUFFIX
arguments could be functions as well as strings, to allow more control
over the printing of this information. That's not essential, but it
would for example make it easier to print special characters.
The :FROM-START and :FROM-POSITION values for KIND in LOGICAL-BLOCK-INDENT
are too easily confused. I suggest renaming them to :BLOCK and :CURRENT
and renaming the argument to RELATIVE-TO.
The functional interface is missing equivalents for the
~/TABULAR-STYLE/, ~/FILL-STYLE/, and ~/LINEAR-STYLE/ features.
I think it's better to provide these as predefined functions
than to make the user define them himself.
∂17-Mar-89 2254 CL-Cleanup-mailer Re: Issue: LOAD-OBJECTS (Version 3)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 17 Mar 89 22:54:01 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 560294; Sat 18-Mar-89 01:50:31 EST
Date: Sat, 18 Mar 89 01:50 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: Issue: LOAD-OBJECTS (Version 3)
To: Sandra J Loosemore <sandra%defun@cs.utah.edu>, Richard P. Gabriel <rpg@lucid.com>
cc: CL-Cleanup@sail.stanford.edu, CL-Compiler@sail.stanford.edu, Common-Lisp-Object-System@sail.stanford.edu
In-Reply-To: <8903120142.AA00878@defun.utah.edu>
Message-ID: <19890318065022.2.MOON@EUPHRATES.SCRC.Symbolics.COM>
There are a couple of small changes that seem warranted:
MAKE-LOAD-FORM-USING-SLOTS is too easy to confuse with
SLOT-VALUE-USING-CLASS. MAKE-LOAD-FORM-FROM-SLOTS is better,
except for form/from dyslexia. MAKE-LOAD-FORM-FOR-SLOTS ?
Maybe there should be a SIMILAR-AS-CONSTANTS generic function
for the benefit of CONSTANT-COLLAPSING. In the absence of that
we're just using EQ.
On the subject of this proposed alternative:
Date: Sat, 11 Mar 89 18:42:56 MST
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Have two generic functions, not one. The first would get called by
compile-file and it would return a list of components (or whatever)
that are required to reconstruct the object. The compiler would dump
this list of objects in its usual way. The loader would apply the
second generic function to this list to reconstruct the object.
This is exactly the way I did the first implementation of this idea,
back in about 1978. It didn't work very well, basically for two reasons.
One is that representing information in the form of lists is pretty
impoverished and it's very easy to get the list the wrong length or
out of order; it's also more difficult than it should be to make
upward-compatible changes, because the new format always has to be
a superset of the old format. Forms are more general. You can make
upward-compatible changes by inventing a new function name and keeping
the old function name around forever with the old semantics; this also
ensures an undefined-function error if the new format is loaded into
the old system.
The second reason is more serious. The way you propose cannot be nicely
extended to deal with circular structures, because it fails to separate
object creation from object initialization. The second generic function
does both operations. My application used circular structures
extensively and had a fairly horrible kludge for them, involving standin
objects that were replaced with the correct objects later in loading;
this was fragile and permeated the reconstruction methods, all the worst
characteristics for this kind of thing.
On the subject of forms versus functions as the interface, I think
David Gray has expressed very well the reasons why that is not
practical, at least at Common Lisp's present stage of development.
I've read all the mail on the subject, but I stand by LOAD-OBJECTS
version 3. There may be more thought behind this proposal than is
apparent at first glance.
∂17-Mar-89 2300 CL-Cleanup-mailer Re: Issue: TYPE-OF-UNDERCONSTRAINED, v.5
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 17 Mar 89 23:00:36 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 560300; Sat 18-Mar-89 01:57:45 EST
Date: Sat, 18 Mar 89 01:57 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: Issue: TYPE-OF-UNDERCONSTRAINED, v.5
To: masinter.pa@Xerox.COM
cc: cl-cleanup@sail.stanford.edu
In-Reply-To: <890317-221413-3463@Xerox>
Message-ID: <19890318065727.3.MOON@EUPHRATES.SCRC.Symbolics.COM>
Line-fold: No
Date: 17 Mar 89 22:09 PST
From: masinter.pa@Xerox.COM
I think BIT-VECTOR might have been an omission.
NULL was left out because it seemed silly and at odds with current practice
to require that (TYPE-OF 'NIL) = NULL. However, if (CLASS-OF 'NIL) is the
special NULL class, then we would have to reconsider.
In Symbolics Genera 7.4, (TYPE-OF 'NIL) => NULL, so that's some current
practice. 88-002R mandates (SUBTYPEP (CLASS-OF 'NIL) (FIND-CLASS 'NULL)).
SEQUENCE was left out because it is an 'abstract' class and is (as far as
the standard is concerned) exhaustively partitioned by VECTOR and LIST
which are already "lower bounds" of TYPE-OF.
It is not an exhaustive partition, according to CLtL p.35. I put
SEQUENCE in so that if an implementation adds a third kind of SEQUENCE,
TYPE-OF can't be any less specific than SEQUENCE. This is the same reason
that RATIONAL, FLOAT, and NUMBER are in.
BIGNUM and FIXNUM were left out because their division was implementation
dependent.
KEYWORD was left out because under odd circumstances it is possible to
dynamically change the 'type' (e.g., by UNINTERN).
STANDARD-CHAR and STRING-CHAR were left out for the same reasons they
aren't built-in classes.
I'll buy the above three paragraphs, although I don't think any of them
are 100% compelling.
∂17-Mar-89 2320 CL-Cleanup-mailer Re: Issue: PLUS-ABNORMAL (Version 1)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 17 Mar 89 23:20:10 PST
Received: from Semillon.ms by ArpaGateway.ms ; 17 MAR 89 23:17:01 PST
Date: 17 Mar 89 23:16 PST
From: masinter.pa@Xerox.COM
Subject: Re: Issue: PLUS-ABNORMAL (Version 1)
In-reply-to: masinter.pa's message of 15 Mar 89 07:33 PST
To: CL-Cleanup@SAIL.Stanford.EDU, skona%csilvax@hub.ucsb.edu
Message-ID: <890317-231701-3536@Xerox>
Can we drop this one? Complaints only.
∂17-Mar-89 2357 CL-Cleanup-mailer Re: environment argument for SUBTYPEP
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 17 Mar 89 23:57:39 PST
Received: from Semillon.ms by ArpaGateway.ms ; 17 MAR 89 23:54:56 PST
Date: 17 Mar 89 23:54 PST
From: masinter.pa@Xerox.COM
Subject: Re: environment argument for SUBTYPEP
In-reply-to: David N Gray <Gray@DSG.csc.ti.com>'s message of Wed, 11 Jan 89
15:57:47 CST
To: David N Gray <Gray@DSG.csc.ti.com>, cl-cleanup@sail.stanford.edu, "Kim
A. Barrett" <IIM@ECLA.USC.EDU>
Message-ID: <890317-235456-3561@Xerox>
Somehow I dropped some mail; I don't have the proposal, although there's a
reference to version 1 of SUBTYPEP-ENVIRONMENT. Is this ready?
∂18-Mar-89 0026 CL-Cleanup-mailer [cl-cleanup@sail.stanford.edu: Issue:
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 18 Mar 89 00:26:17 PST
Received: from Semillon.ms by ArpaGateway.ms ; 18 MAR 89 00:24:02 PST
Date: 18 Mar 89 00:22 PST
From: masinter.pa@Xerox.COM
Subject: [cl-cleanup@sail.stanford.edu: Issue:
UNDEFINED-VARIABLES-AND-FUNCTIONS (Version 1)]
To: rpg@lucid.com, gregor.pa@Xerox.COM
cc: cl-cleanup@sail.stanford.edu
line-fold: NO
Message-ID: <890318-002402-3587@Xerox>
Moon's notes from Jan 89 X3J13:
"Lumping SLOT-UNBOUND in with unbound special variables was a mistake,
as SLOT-UNBOUND is an extension mechanism, not only a safety checking
mechanism. Also there were some wording problems. Gabriel and Gregor
are to submit a revised proposal."
No revised proposal has been submitted.
Now that you know what "safe" is, you can safely do so. Eh?
----- Begin Forwarded Messages -----
Date: 11 Jan 89 23:45 PST
Sender: masinter.pa
Subject: Issue: UNDEFINED-VARIABLES-AND-FUNCTIONS (Version 1)
To: X3J13@Sail.Stanford.Edu
Reply-to: cl-cleanup@sail.stanford.edu
From: cl-cleanup@sail.stanford.edu
cc: masinter
line-fold: No
It was believed that this issue might be controversial.
!
Issue: UNDEFINED-VARIABLES-AND-FUNCTIONS
References: 5.1.2 Variables (CLtL pp55-56),
Slots (88-002R, p1-10)
Category: CHANGE
Edit history: 29-Nov-88, Version 1 by Pitman
Problem Description:
CLtL does not specify what happens if you attempt to call a named function
which is in fact undefined. In most implementations, it would be devastating to
actually jump to code which you had not verified to be a function, so this error
should be easily caught -- yet, CLtL does not guarantee that an error will be
signalled even in the safest, least fast OPTIMIZE settings.
CLtL (p56) specifies that "it is an error to refer to a variable that is unbound."
CLOS (p1-10) specifies that "when an unbound slot is read, the generic function
SLOT-UNBOUND is invoked. The system-supplied primary method for SLOT-UNBOUND
signals an error."
CLOS and CLtL are not in agreement on their treatment of unbound variables.
CLtL is very weak in that it guarantees no support for reliably detecting
and signalling an error when the error situation occurs, even in the safest,
least fast OPTIMIZE setting.
CLOS is very strong in that it forces detection of the error in all
situations -- even in the fastest, least safe OPTIMIZE setting.
The disparate positions for treatment of variables and slots should be
reconciled, either by finding a compromise or by justifying the apparent
inconsistency. The final story should explain function references as well.
Proposal (UNDEFINED-VARIABLES-AND-FUNCTIONS:COMPROMISE):
Define that reading an undefined function, an unbound variable, or
an unbound slot must be detected in the highest safety setting,
but the effect is undefined in any other safety setting. That is,
- Reading an undefined function should signal an error.
- Reading an an unbound variable should signal an error.
- Reading an unbound slot should invoke the function SLOT-UNBOUND.
By ``reading an undefined function'' in the above, we mean to
include both references to the function using the FUNCTION
special form, such as F in (FUNCTION F) and references to the
function in a call, such as F in (F X).
For the case of INLINE functions (in implementations where they are
supported), it is permissible to consider that performing the inlining
constitutes the read, so that an FBOUNDP check need not be done at
execution time. Put another way, the effect of FMAKUNBOUND of a function
on potentially inlined references to that function is undefined.
Specify that the type of error signalled when an undefined function
is detected is UNDEFINED-FUNCTION, and that the NAME slot of the
UNDEFINED-FUNCTION condition is initialized to the name of the
offending function.
Specify that the type of error signalled when a unbound variable
is detected is UNBOUND-VARIABLE, and that the NAME slot of the
UNBOUND-VARIABLE condition is initialized to the name of the
offending variable.
Introduce a new condition type, UNBOUND-SLOT, which inherits from
CELL-ERROR. This new type has an additional slot, INSTANCE, which
can be initialized using the :INSTANCE keyword to MAKE-CONDITION.
Introdue a new function UNBOUND-SLOT-INSTANCE to access INSTANCE slot.
Specify that the type of error signalled by the default primary
method for the SLOT-UNBOUND generic function is UNBOUND-SLOT,
and that the NAME slot of the UNBOUND-SLOT condition is initialized
to the name of the offending variable, and that the INSTANCE slot
of the UNBOUND-SLOT condition is initialized to the offending instance.
Test Case:
(PROCLAIM '(OPTIMIZE (SAFETY 3) (SPEED 0)))
(DEFUN FOO () X)
(FOO)
>>Error: The variable X is not bound.
...
Rationale:
This makes it easier to treat slots like variables.
This makes it possible to better rely on an unbound variable error being
signalled when one has occurred.
This makes it possible to compile out useless error checking in CLOS
code where the code is debugged and the checking is redundant.
For the case of undefined functions, blindly jumping to an undefined
function is an incredibly dangerous thing to do. Every implementation
should guarantee at least some way to get error checking of undefined
functions.
Current Practice:
Until recently, Symbolics Cloe did not ever signal an error on unbound
variable, even in the safest case. The excuse was that this was a CLtL
didn't require it, but it was sometimes an impediment to debugging.
Some benchmarks for Symbolics Cloe (which currently only claims to
implement New Flavors, not CLOS) could be faster if checking for unbound
instance variables could be optimized away.
Symbolics Genera doesn't care about safety issues in variable access
because the check can be done by microcode.
Cost to Implementors:
This change does not force a change to any current implementation, except
those which do not yet signal unbound variable or undefined function errors
even in the safest setting.
Cost to Users:
This checking might slow down some code which is written for the safest
setting yet does not need this check.
Any implementation-specific code which depended on these references not
signalling would be broken. Such code was not portable, of course.
Any CLOS code which depends on SLOT-UNBOUND being called even in low safety
settings would be broken. The amount of such code at this point is likely
to be little or none. If such cases did exist, local or global changes to
safety settings would correct the problem (at some cost in speed).
Cost of Non-Adoption:
Some important error checking would not occur.
Some important optimizations could not be done.
The language would seem internally less consistent.
Benefits:
The costs of non-adoption would be avoided.
Aesthetics:
This would regularize things a little.
Discussion:
Pitman thinks this would be a good idea.
----- End Forwarded Messages -----
∂18-Mar-89 0122 CL-Cleanup-mailer Cleanup Issue Status List
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 18 Mar 89 01:22:13 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 18 MAR 89 01:19:53 PST
Date: 18 Mar 89 01:19 PST
From: masinter.pa@Xerox.COM
to: cl-cleanup@sail.stanford.edu
Subject: Cleanup Issue Status List
Message-ID: <890318-011953-3626@Xerox>
I think this issue status is up to date.
I think I have updated versions of all pending and passed
issues stored on arisia.xerox.com under the
clcleanup/pending
clcleanup/passed
directories respectively.
I'm pretty much unavailable (travelling, etc.)
until the meeting. If there are new versions
of any issues that are ready for release, or any
new issues that are important, please email to X3J13.
I'll try to read my mail while on the road, but
it will be difficult to handle the quantity we've
seen in the last week.
I'll send a short version of this list to X3J13.
Codes:
! released for Jan 89 meeting
+ passed
- withdrawn, failed, tabled indefinitely, etc.
* need new version
!*: released, but I know we'll need a new version
+*: passed, but need to reconsider
!*: passed, but need a new version to reconsider
!
+ ADJUST-ARRAY-DISPLACEMENT
Version 4, 23-Nov-87
Status: passed, 1988
+ ADJUST-ARRAY-FILL-POINTER
Version 1, 15-MAR-88
Status: passed, 1988
! ADJUST-ARRAY-NOT-ADJUSTABLE
Synopsis: ADJUST-ARRAY on array made with :ADJUSTABLE NIL: "an error"?
Version 4, 11-Jan-89, Released 12-Jan-89
Status: Accepted with amendments Jan 89 X3J13
Comments: amendment had wording problem.
Version 8, 11-Mar-89, Released 15-Mar-89
Status: ready for vote
- ALIST-NIL
Version 4, 1-Oct-88
Status: Withdrawn, recommend editorial
- APPEND-ATOM
Synopsis: atom case of APPEND (left out of APPEND-DOTTED)
Version 1, 6-Dec-88, Released 12-Jan-89
Status: withdrawn 18-Jan-89 because APPEND-DOTTED withdrawn
- APPEND-DOTTED
14-JAN-88, Version 5
Status: Passed Nov 88 X3J13, reconsidered & withdrawn Jan 89 X3J13
+ APPLYHOOK-ENVIRONMENT
Synopsis: remove (useless) env argument to applyhook
Version 2, 10-Jan-89, Released 10-Jan-89
Status: Passed Jan-89 X3J13
+ AREF-1D
14-NOV-87, Version 7
Status: Passed, 1988?
+ ARGUMENTS-UNDERSPECIFIED
Synopsis: Clarify various ranges missing from CLtL
Version 4, 21-Sep-88, Released 4 Dec 88
Status: Passed Jan 89 X3J13
+ ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS
Synopsis: What do array element-type declarations mean?
Version 9, 31-Oct-88, Released 5 Dec 88
Status: Passed Jan 89 X3J13
+ ASSOC-RASSOC-IF-KEY
Version 4, 23-NOV-87
Status: Passed, 1988?
- BACKQUOTE-COMMA-ATSIGN-DOT
Synopsis: `(... ,@x) vs `(... . ,x). Same, different, is error?
Version 1, 22-Dec-88, DRAFT released
Comments: proposals INTERCHANGABLE and DIVERGENT comments not in writeup
Status: Withdrawn, since APPEND-DOTTED withdrawn. Default is IS ERROR
! BREAK-ON-WARNINGS-OBSOLETE
Synopsis: deprecate *BREAK-ON-WARNINGS* because of *BREAK-ON-SIGNALS*
Version 1, 07-Mar-89, Released 15-Mar-89
Comment: leaves out a case
Status: ready for vote
! CLOS-CONDITIONS
Version 4, 10-Mar-89
Comments: define metaclass of conditions?
Status: pending
+ CLOSE-CONSTRUCTED-STREAMS
Synopsis: What does it mean to CLOSE a constructed stream?
Version 2, 12-Jan-89, Released 12-Jan-89
Status: Proposal ARGUMENT-STREAM-ONLY passed Jan 89 X3J13
!+ CLOSED-STREAM-OPERATIONS
Synopsis: What operations are legal on closed streams?
Version 5, 5-Dec-88, released 5-Dec-88
Status: amended at meeting
Version 7, 14-Feb-89
Status: Passed, as amended, Jan 89 X3J13
Comment: amendment bad; reconsider version 5.
say that INPUT-STREAM-P and OUTPUT-STREAM-P
are undefined on closed streams?
! COERCE-INCOMPLETE
Synopsis: Extend COERCE
Version 3, 7-Mar-89, Released 14-Mar-89
Status: ready for voting
+ COLON-NUMBER
Synopsis: :123 is an error
22-OCT-87, Version 1
Status: Passed, 1988?
+ COMPILER-WARNING-STREAM
Version 6, 5-JUN-87
Status: Passed, 1988?
+ COMPLEX-ATAN-BRANCH-CUT
Synopsis: tweak upper branch cut in ATAN formula
Version 1, 13-Dec-88, Released 10-Jan-89
Status: Passed Jan 89 X3J13
!* CONDITION-RESTARTS
Synopsis: can't know whether restart is associated with signalling
Version 1, 18-Jan-89, released 16-Mar-89
Comment: (proposed amendments)
Status: need new version
+ CONTAGION-ON-NUMERICAL-COMPARISONS
Version 1, 14-Sep-88, Released 6 Oct 88
Status: passed, Jan 89 X3J13
! COPY-SYMBOL-COPY-PLIST
Version 1, 10-Jan-89, released 16-Mar-89
Status: ready for vote
! COPY-SYMBOL-PRINT-NAME
Version 2, 15-Mar-89, released 16-Mar-89
Status: ready for vote
+ DATA-TYPES-HIERARCHY-UNDERSPECIFIED
4-SEP-88 Version 2
Status: Passed, 1988?
+ DECLARATION-SCOPE
Version 4, 15-Nov-88, Released 9-Dec-88
Status: NO-HOISTING passed Jan 89 X3J13
+ DECLARE-ARRAY-TYPE-ELEMENT-REFERENCES
Version 3, 13-Jan-89
Status: passed, Jan 89 X3J13
+ DECLARE-FUNCTION-AMBIGUITY
Version 4, 5-Dec-88, Released 5-Dec-88
Status: passed, Jan 89 X3J13
+ DECLARE-MACROS
5-FEB-88, Version 3
Status: Passed, 1988?
+ DECLARE-TYPE-FREE
Version 10, 12-Jan-89
Status: proposal LEXICAL passed Jan 89 X3J13
- DECLARE-TYPE-USER-DEFINED
Synopsis: allow (declare ((signed-byte 8) x y z)) for all type specifiers?
Status: Withdrawn (never submitted)
+ DECODE-UNIVERSAL-TIME-DAYLIGHT
Version 2, 30-Sep-88, Released 6 Oct 88
Status: Passed, Jan 89 x3j13
- DEFINITION-DELETE
Synopsis: provide a way to get rid of structures, etc.
Status: not submitted
* DEFMACRO-LAMBDA-LIST
Version 2, 17-Mar-89
Status: ready for release?
+ DEFPACKAGE
Version 7, 2-Nov-88, Released 5 Dec 88
Comment: clarify "at variance" in editorial work?
Status: Passed, Jan 89 X3J13
- DEFSTRUCT-ACCESS-FUNCTIONS-INLINE
Synopsis: defstruct accessors are proclaimed inline
Version 2, 7-Jan-89, released 10-Jan-89
Status: rejected, Jan 89 X3J13
+ DEFSTRUCT-CONSTRUCTOR-KEY-MIXTURE
Version 3, 8-Jan-89, Released 11-Jan-89
Status: Passed, Jan 89 X3J13
+ DEFSTRUCT-DEFAULT-VALUE-EVALUATION
Version 1, 5/13/88
Status: Passed, 1988
+ DEFSTRUCT-PRINT-FUNCTION-INHERITANCE
Version 3, 7 Dec 88, Released 12-Dec-88
Status: Passed, Jan 89 X3J13
+ DEFSTRUCT-REDEFINITION
Synopsis: what happens if you redefine a DEFSTRUCT?
Version 3, 6-Feb-89
Status: Passed (as amended) Jan 89 X3J13
+ DEFSTRUCT-SLOTS-CONSTRAINTS-NAME
Version 5, 12-Jan-89
Status: Passed, Jan 89 X3J13
+ DEFSTRUCT-SLOTS-CONSTRAINTS-NUMBER
Version 1, 5/13/88
Status: Passed, 1988
+ DEFVAR-DOCUMENTATION
23-NOV-87, Version 2
Status: Passed, 1988?
+ DEFVAR-INIT-TIME
29-MAR-87, Version 2
Status: Passed, 1988?
+ DEFVAR-INITIALIZATION
Version 4 5-JUN-87
Status: Passed, 1988?
- DELETE-FILE-NONEXISTENT
Version 1, 5-Oct-88
Comments: should just signal different errors?
Status: withdrawn/tabled?
+ DESCRIBE-INTERACTIVE
Version 4, 15-Nov-88, Released 7-Dec-88
Synopsis: can DESCRIBE ask user a question?
Status: Proposal NO passed Jan 89 X3J13
! DESCRIBE-UNDERSPECIFIED
Version 1, 10-Mar-89, Released 16-Mar-89
Synopsis: making DESCRIBE generic was wrong; fix
status: ready for vote
!* DESTRUCTURING-BIND
Version 2, 25-Jan-89, Released 16-Mar-89
Synopsis: add DESTRUCTURING-BIND macro
Status: might need new version before vote
+ DISASSEMBLE-SIDE-EFFECT
Version 3 1/21/88
Status: Passed, 1988
+ DO-SYMBOLS-DUPLICATES
Version 3 23-NOV-87
Status: Passed, 1988?
+ DOTTED-MACRO-FORMS
Version 3, 15-Nov-88, Released 7-Dec-88
Status: passed, Jan 89 X3J13
+ DRIBBLE-TECHNIQUE
14-FEB-88, Version 2
Status: Passed, 1988?
! DYNAMIC-EXTENT
Version 3, 11-Jan-89, released 16-Mar-89
Comments: still some holes
Status: ready for vote?
- ELIMINATE-FORCED-CONSING
Synopsis: Add :RECYCLE or :MODIFY to some sequence fns,
Version 3, 31-Aug-88
Status: withdrawn
- ENVIRONMENT-ENQUIRY
Synopsis: "The environment inquiry functions (pp447-448) don't return a
value in consistent format across implementations. This makes
them virtually useless. I would like to constrain the values
enough so that implementors knew what to provide as return
values, and provide some examples of intended uses."
Status: no volunteer to submit
+ EQUAL-STRUCTURE
Version 6, 11-Jan-89, Released 12-Jan-89
Status: Passed with amendments
Version 7, 15-Mar-89
Status: Passed Jan 89 X3J13 as amended.
* EQUALP-GENERIC
Version 1, 28-Feb-89
Synopsis: make EQUALP generic function
Comments: Various problems being worked on
Status: ** NEED NEW VERSION ***
* ERROR-CHECKING-IN-NUMBERS-CHAPTER
Version 1, 6-Mar-89
Synopsis: define 'should signal', 'might signal' for number fns
Status: ** NEED NEW VERSION **
! ERROR-NOT-HANDLED
Version 1, 25-Sep-88, Released 6-Oct-88 and 14-Mar-89
Status: ready for vote
+ EVAL-OTHER
8-JUN-88, Version 2
Status: Passed, 1988?
! EXIT-EXTENT
Version 6, 8-Jan-89, distributed at Jan89 X3J13
Rereleased 16-Mar-89
Status: tabled Jan89; ready for vote
+ EXPT-RATIO
Version 3, 31-Oct-88, Released 7 Dec 88
Status: passed, Jan 89 X3J13
- EXPT-ZERO-ZERO
Synopsis: (EXPT 0.0 0.0) should be undefined
Version 1, 27-Feb-89
Status: withdrawn
- FILE-LENGTH-PATHNAME
Synopsis: extend FILE-LENGTH to work on pathnames
Status: not submitted/ withdrawn
- FILE-WRITE-DATE-IF-NOT-EXISTS
Synopsis: What does FILE-WRITE-DATE do if no such file?
Version: no proposal
Status: => ERRORS-IN-FILE-SYSTEM-CHAPTER????
+ FIXNUM-NON-PORTABLE
Version 4, 7-Dec-88, Released 12-Dec-88
Version 6, 17-Mar-89, as amended
Status: Passed, Jan 89 X3J13, as amended
+ FLET-DECLARATIONS
Version 2, 2 FEB 88
Status: Passed, 1988?
+ FLET-IMPLICIT-BLOCK
Version 6 5-JUN-87
Status: Passed, 1988?
- FOLLOW-SYNONYM-STREAM
Comment: lost in STREAM-ACCESS.
Status: Withdrawn?
+ FORMAT-ATSIGN-COLON
Version 4 5-JUN-87
Status: Passed, 1988?
+ FORMAT-COLON-UPARROW-SCOPE
Version 3, 5 FEB 88
Status: Passed, 1988?
+ FORMAT-COMMA-INTERVAL
Version 2, 15-JUN-87
Status: Passed, 1988?
+ FORMAT-E-EXPONENT-SIGN
Version 2, 2 Oct 88, Released 6 Oct 88
Status: Passed, Jan 89 X3J13
+ FORMAT-OP-C
11-JUN-87, Version 5
Status: Passed, 1988?
- FORMAT-NEGATIVE-PARAMETERS
Synopsis: What does FORMAT do when it gets negative numbers for count?
Version: No proposal
Comment: KMP will incorporate in the list-of-signals part of the signal
proposal?
Status: not submitted
* FORMAT-PLURALS
Synopsis: remove ~P, add ~:@[singular~;plural~]
Status: no proposal
+ FORMAT-PRETTY-PRINT
Version 7, 15 Dec 88, Released 7 Dec 88
Comments: passed, Jan 89 X3j13
- FORMAT-ROUNDING
Synopsis: specify that ~F rounds up
Version 1, 5-Oct-88
Status: withdrawn
- FUNCTION-ARGUMENT-LIST
Synopsis: want way to get argument list
Status: not submitted
+ FUNCTION-CALL-EVALUATION-ORDER
Version 1, 22-MAR-88
Status: Passed, 1988
! FUNCTION-COERCE-TIME
Synopsis: When does SYMBOL-FUNCTION happen in MAPCAR?
Version 2, 16-sep-88, Released 8-Oct-88
Re-released: 16-Mar-89
Status: ready for vote?
+ FUNCTION-COMPOSITION
Synopsis: Add new functions
Version 5, 10-Feb-89
Status: Passed (as amended) Jan 89 X3J13
maybe this was passed as amendment to TEST-NOT-IF-NOT instead
+ FUNCTION-DEFINITION
Version 3, 10-Feb-89
Status: Passed (as amended) Jan 89 X3J13
! FUNCTION-NAME
Comment: renaming of SETF-FUNCTION-VS-MACRO, SETF-PLACES
SETF-FUNCTION-VS-MACRO
Version 3, 4-Nov-87, Released Nov 87
SETF-PLACES
Version 1, 11-Nov-88, Released 9-Dec-88
FUNCTION-NAME
Version 1, 27-Jan-89, Released 16-Mar-89
Status: ready for vote
+ FUNCTION-TYPE
Version 12, 4-SEP-88
Status: Passed, June 1988 X3J13, as amended
+ FUNCTION-TYPE-ARGUMENT-TYPE-SEMANTICS
Synopsis: Change semantics of argument types in function declarations
Version 3, 7-Dec-88, Released 12-Dec-88
Status: Passed, Jan 89 X3J13
+ FUNCTION-TYPE-KEY-NAME
Version 3, 13-FEB-88
Status: Passed, 1988
+ FUNCTION-TYPE-REST-LIST-ELEMENT
Version 5, 14-Nov-88, Released 8-Dec-88
Status: Passed, Jan 89 X3J13
- GCD-NO-ARGUMENTS
Synopsis: make (GCD) undefined
Status: not submitted
! GENSYM-NAME-STICKINESS
Synopsis: no side effects if optional arg supplied
Version 1, 14-Feb-89, Released 14-Mar-89
Status: comments
Version 2, 16-Mar-89
Status: ready for release?
- GET-MACRO-CHARACTER-DISPATCHING
Synopsis: What does GET-MACRO-CHARACTER return for dispatching macros?
Status: not submitted
+ GET-MACRO-CHARACTER-READTABLE
Version 3, 11-Feb-89
Status: Passed (as amended) Jan 89 X3J13
+ GET-SETF-METHOD-ENVIRONMENT
Version 5 13-JUL-87
Status: Passed, 1988?
! HASH-TABLE-ACCESS
Synopsis: Add new accessors for hash-table properties
Version 1, 13-Sep-88 released 8-Oct-88
Version 2, 13 Oct 88, released 16-Mar-89
status: vote
- HASH-TABLE-GC
Synopsis: allow hash tables with GCable keys
Status: no proposal
+ HASH-TABLE-PACKAGE-GENERATORS
Version 7, 8-Dec-88, Released 9-Dec-88
Comments: The test-package-iterator example has the values
from the generator in the wrong order.
Status: passed, Jan 89 X3J13
* HASH-TABLE-PRINTED-REPRESENTATION
Version 2, 8-Jun-88
Comments: Use #S(ARRAY ...), #S(HASH-TABLE...), #S(PATHNAME...)?
Status: need new proposal
- HASH-TABLE-STABILITY
Version 1, 11-Nov-88, Released 12 Dec 88
Comments: superceded HASH-TABLE-KEY-MODIFICATION
Status: Rejected Jan 89 X3J13
+ HASH-TABLE-TESTS
Version 2, 8-Dec-88, Released 8 Dec 8 8
Status: passed Jan 89 X3J13
+ IEEE-ATAN-BRANCH-CUT
Version 2, 11-Jan-89, Released 11-Jan-89
Status: passed, Jan 89 X3J13
* IGNORE-VARIABLE
Synopsis: default (IGNORE IGNORE)
Version 1, 6-Feb-89
+ IMPORT-SETF-SYMBOL-PACKAGE
Version 5 ??-MAY-87
Status: Passed, 1988?
! IN-PACKAGE-FUNCTIONALITY
Version 4, 12-Dec-88, Released 12-Dec-88
Status: tabled
Version 8, 15-Mar-89, Released 15-Mar-89
Status: ready for vote
- IN-SYNTAX
Synopsis: like IN-PACKAGE but for readtables
Version 1, 21-Oct-88
Comments: important issue: default environment for LOAD
Status: can we withdraw?
- INPUT-STREAM-P-CLOSED
Synopsis: What do INPUT-STREAM-P and OUTPUT-STREAM-P do on closed streams?
Status: not submitted
- INPUT-STREAM-P-EXAMPLE
Synopsis: (input-stream-p (make-broadcast-stream)) is NIL
Version 1, 26-Oct-88
Status: bug report, needs no clarification?
+ KEYWORD-ARGUMENT-NAME-PACKAGE
8-NOV-87, Version 8
Status: Passed, 1988?
- LAMBDA-FORM
Version 4, 22-Nov-88, Released 8-Dec-88
Status: rejected, Jan 89 X3J13
+ LAST-N
12-MAR-88, Version 2
Status: Passed, 1988?
+ LCM-NO-ARGUMENTS
Version 1, 17 Oct 88, Released 8 Dec 88
Status: passed, Jan 89 X3J13
- LEAST-POSITIVE-SINGLE-FLOAT-NORMALIZATION
Synopsis: should LEAST-POSITIVE- and MOST-POSITIVE-XXX-FLOAT
numbers include denormalized ones in those implementations
that admit them?
Status: Not submitted
! LISP-PACKAGE-NAME
Synopsis: change LISP to COMMON-LISP to avoid CLtL confusion
Version 1, 22 Dec 88, Released 11-Jan-89
Status: tabled; version 1 still ready for vote
! LISP-SYMBOL-REDEFINITION
Version 5, 22-Nov-88, Released 8 Dec 88
Comments: Don't like (DEFVAR CAR ...) example
14: Like simpler "Redefining any documented
definition on a symbol in the LISP package -- such as variables,
functions, constants, properties and property-lists, etc -- is
undefined, except for the explicitly allowed cases (e.g. dynamic
binding of variables)."
Status: tabled; version 5 still ready for vote
- LIST-TYPE-SPECIFIER
Synopsis: add a type specifier (LIST NUMBER)
Version 1, 28 Jun 88
Status: withdrawn
! LOAD-OBJECTS
Synopsis: Provide a way to allow defstruct/defclass objects in compiled files
Version 3, 9-Mar-89, released 16-Mar-89
Status: ready for vote?
! LOAD-TRUENAME
Synopsis: Make default pathname for LOAD inside LOAD same?
Version 1, 13-Mar-89, Released 16-Mar-89
Status: ready for vote
! LOCALLY-TOP-LEVEL
Version 2, 16-Mar-89, released 17-Mar-89
Status: ready to vote
! LOOP-AND-DISCREPANCY
Version 1, 15-Mar-89, released 16-Mar-89
status: ready for vote
+ MACRO-FUNCTION-ENVIRONMENT
Version 2, 8-JUN-88
Status: Passed, 1988
* MACRO-SPECIAL-FORMS
Synopsis: macros => implementation-dependent special forms doesn't work
Status: *** NEED PROPOSAL SUBMITTED ****
- MAKE-CONCATENATED-STREAM-EXAMPLE
Synopsis: (read (make-concatenated-stream (make-string-input-stream "1")
(make-string-input-stream "2"))) => 12?
Version 1, 26-Oct-88
Status: withdrawn, no issue (bug report to one implementation)
+ MAKE-PACKAGE-USE-DEFAULT
Version 2, 8 Oct 88, Released 12-Dec-88
Version 3, 16-Mar-89
Status: Passed, Jan 89 X3J13 as amended
! MAKE-STRING-FILL-POINTER
Synopsis: extend MAKE-STRING to take a fill-pointer?
Version 1, 20-Oct-88, released 16-Mar-89
Status: ready for vote
+ MAPPING-DESTRUCTIVE-INTERACTION
Version 2, 09-Jun-88, Released 8 Oct 88
Synopsis: [don't] define interaction of DELETE on MAPCAR'd list.
Status: passed, Jan 89 X3J13
+ NTH-VALUE
Version 4, 8-Dec-88, Released 8 Dec 88
Comment: amended to clarify when index out of range
Version 5, 17-Mar-89
Status: passed, as amended
- OUTPUT-STREAM-P-EXAMPLE
Synopsis: Clarify (output-stream-p (make-concatenated-stream)) is NIL?
Version 1, 26-Oct-88
Comment: already clear; just bug report for one implementation
+ PACKAGE-CLUTTER
Version 6, 12-Dec-88, Released 12-Dec-88
Comments: Accepted, with amendment
Version 7, 17-Mar-89
Status: Passed, Jan 89 X3J13, as amended
+ PACKAGE-DELETION
Version 5, 21 nov 88, Released 8 Dec 88
Comments: Minor glitches? Remove the description of "correctable" error to be signalled and
handled.
Status: passed, Jan 89 X3J13
!+ PACKAGE-FUNCTION-CONSISTENCY
Synopsis: allow strings for package arg everywhere uniformly
Version 2, 12-Jan-89, Released 12-Jan-89
Comment: Accepted MORE-PERMISSIVE with amendments
Version 3, 17-Mar-89, released 17-Mar-89
Status: vote to accept wording as intent of amendment
* PATHNAME-CANONICAL-TYPE
Synopsis: allow canonical :SOURCE-LISP to MAKE-PATHNAME;
require PATHNAME-TYPE to return same?
Version 1, 07-Jul-88
Comments: only add the :TYPE :SOURCE-LISP, not PATHNAME-CANONICAL-TYPE?
Status: => "pathname" committee?
- PATHNAME-COMPONENT-CASE
Synopsis: allow ALL UPPER CASE to mean "use the 'right' case
Comments: lots of heat?
Status: withdraw?
- PATHNAME-EXTENSIONS
Synopsis: allow a way of telling whether a pathname is a pattern, a "funny"
file
Comments: necessary in standard?
Status: => "pathname" committee
* PATHNAME-LOGICAL
Synopsis: add logical pathnames (pathnames for an imaginary portable
file system, which get translated by site-dependent translations into
physical pathnames on an actual file system)
Status: no proposal yet
* PATHNAME-PRINT-READ
Synopsis: Print pathnames like #P"asdf"?
Version 1, 21-Oct-88
Comments: Numerous, pro, con. Print like #S(pathname ...)?
Status: *** NEED NEW VERSION ***
+ PATHNAME-STREAM
Version 6 14-NOV-87
Status: Passed, 1988?
+ PATHNAME-SYMBOL
Version 5 5-FEB-88
Status: Passed, 1988?
* PATHNAME-SUBDIRECTORY-LIST
Synopsis: How to deal with subdirectory structures in pathname functions
Version 3, 29-Dec-88
Comments: typos and proposed simplifications
Status: *** NEED NEW VERSION ***
* PATHNAME-SYNTAX-ERROR-TIME
Synopsis: when are errors in pathnames detected?
Version 1, 7-Jul-88
Comments: various
Status: need new version? ==> ERRORS-IN-FILE-CHAPTERS?
- PATHNAME-TYPE-UNSPECIFIC
Version 1 27-Jun-88, Released 7 Oct 88
Comments: may be subsumed
Status: withdrawn; superceded by PATHNAME-UNSPECIFIC-COMPONENT
+ PATHNAME-UNSPECIFIC-COMPONENT
Synopsis: More extensions to :UNSPECIFIC
Version 1, 29-Dec-88, Released 12-Jan-89
Version 2, 17-Mar-89
Status: Passed, Jan 89 X3j13, as amended
- PATHNAME-WILD
Version 2, 6-Oct-88
Synopsis: Portable way to ask about "wildcard" pathnames?
Comments: consistent with PATHNAME-COMPONENT-CASE?
Status: => "pathname" committee
+ PEEK-CHAR-READ-CHAR-ECHO
Version 3, 8-Oct-88, Released 8 Oct 88
Synopsis: PEEK-CHAR, READ-CHAR on streams made by MAKE-ECHO-STREAM
Status: Passed, Jan 89 X3J13
- PLUS-ABNORMAL
Version 1, 1-Mar-89
Synopsis: say what happens to + when evaluation aborts
Status: withdraw?
* PRETTY-PRINT-INTERFACE
Version 3, 15-Mar-89
Synopsis: standardize interface to prettyprinter
Status: Need new version
+ PRINC-CHARACTER
29-APR-87, Version 2
Status: Passed, 1988?
* PRINT-CIRCLE-SHARED
Synopsis: does *PRINT-CIRCLE* cause shared structure to print with #=?
Status: Not submitted yet ** NEED WRITEUP **
+ PRINT-CIRCLE-STRUCTURE
Version 3, 20 Sep 88, Released 8 Oct 88
Comments: Accepted, with amendment
Version 4, 17-Mar-89
Status: Passed, Jan 89 X3J13, as amended
! PROCLAIM-LEXICAL
Version 9, 8-Dec-88, Released 12-Dec-88
Synopsis: add LEXICAL proclaimation
Comments: lengthy mail; amendments at Jan meeting
Status: tabled, vote on version 9 (w/o amendments)
+ PUSH-EVALUATION-ORDER
Version 5, 25-NOV-87
Status: Passed, 1988?
+ RANGE-OF-COUNT-KEYWORDS
Version 3, 9-Oct-88, Released 14-Oct-88
Status: passed, Jan 89 X3J13
+ RANGE-OF-START-AND-END-PARAMETERS
Version 1, 14-Sep-88, Released 7 Oct 88
Status: passed, Jan 89 X3J13
* READ-CASE-SENSITIVITY
Synopsis: Allow readtables to be case sensitive
Comments: use function or keyword?
Status: need new version
* READ-DELIMITED-LIST-EOF
Synopsis: eof in read deliminted list signals an error
Status: awaiting submission
! REAL-NUMBER-TYPE
Synopsis: add REAL = (OR RATIONAL FLOAT) & range
Version 3, 13-Jan-89, released 16-Mar-89
Status: vote?
+ REDUCE-ARGUMENT-EXTRACTION
Version 3 13-FEB-88
Status: Passed, 1988?
!* REMF-DESTRUCTION-UNSPECIFIED
Synopsis: Specification of side-effect behavior in CL
Version 4, 29-Nov-88, Released 12-Jan-89
Status: straw vote in favor of this, BarMar will make amendments
Version 5, 15-Mar-89
Comment: needs a little work
Status: *** NEARLY READY -- NEED NEW VERSION ****
- REMF-MULTIPLE
Synopsis: What does REMF do if it sees more than one INDICATOR?
Version 2, 12-Jan-89, Released 12-Jan-89
Status: withdrawn ("only applies in 'cannot happen' situation")
+ REQUIRE-PATHNAME-DEFAULTS
Version 6, 9 Dec 88, Released 09 Dec 88
Status: passed, Jan 89 X3j13
+ REST-LIST-ALLOCATION
Version 3, 12-Dec-88, Released 12-Dec-88
Status: proposal MAY-SHARE passed, Jan 89 X3J13
- REST-LIST-EXTENT
Synopsis: allow way to declare dynamic extent &REST
Comment: superseded by DYNAMIC-EXTENT
Status: withdrawn
+ RETURN-VALUES-UNSPECIFIED
Version 6, 9 Dec 88, Released 9-Dec-88
Status: passed, Jan 89 X3J13
+ ROOM-DEFAULT-ARGUMENT
Version 1, 12-Sep-88, Released 8 Oct 88
Status: passed, Jan 89 X3J13
- SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS
Version 6, 06-Oct-88, Released 11-Jan-89
Comments: New version scales down previously rejected version
Status: Version 6 rejected Jan 89 X3J13
* SETF-MULTIPLE-STORE-VARIABLES
Synopsis: Allow multiple "places" in SETF stores
Version 1, 5-Dec-88
Status: *** NEED NEW VERSION ****
+ SETF-SUB-METHODS
Version 5, 12-Feb-88, Released 8 Oct 88
Synopsis: careful definition of order inside (SETF (GETF ...) ...)
Status: passed, Jan 89 X3J13
+ SHADOW-ALREADY-PRESENT
Version 4 10-NOV-87
Status: Passed, 1988?
+ SHARPSIGN-PLUS-MINUS-PACKAGE
Version 3 14-NOV-87
Status: Passed, 1988?
- SINGLE-FLOAT-NON-PORTABLE
Synopsis: remove SINGLE-FLOAT, DOUBLE-FLOAT a la FIXNUM?
Status: Not submitted
+ SPECIAL-TYPE-SHADOWING
Synopsis: intersection of types when proclaimed special has local type
declaration
Version 1, 4-Nov-88, released 11-Jan-89
Status: passed, Jan 89 X3J13
- SPECIAL-VARIABLE-TEST
Synopsis: Add SPECIAL-VARIABLE-P?
Version 2, 31-May-88
Status: withdrawn (subsumed by SYNTACTIC-ENVIRONMENT-ACCESS)
+ STANDARD-INPUT-INITIAL-BINDING
Version 8, 8 Jul 88, Released 7 Oct 88
Status: passed, Jan 89 X3J13
- STANDARD-VALUE
Synopsis: user can say binding is "temporary"
Version 1, 21-Oct-88
Comments: not worth trying to standardize now?
Status: withdrawn
+ STEP-ENVIRONMENT
Version 3, 20-Jun-88, Released 7 Oct 88
Version 4, 17-Mar-89
status: Passed, Jan 89 X3J13, as amended
+ STREAM-ACCESS
Version 2, 30-Nov-88, Released 9 Dec 88
Status: ADD-TYPES-ACCESSORS passed, Jan 89 X3J13
- STREAM-CAPABILITIES
Version 1, 7/5/88
Synopsis: SAME-SOURCE-P, SAME-DESTINATION-P, etc
Status: => pathname/file bucket. Withdraw?
- STREAM-DEFINITION-BY-USER
Synopsis: Want user-definable stream types.
Status: not submitted => CL-Windows
- STREAM-ELEMENT-TYPE-EXAMPLES
Version 1, 26-Oct-88
Synopsis: clarify STREAM-ELEMENT-TYPE may return different values?
Status: => editorial
- STREAM-INFO
Version 6, 30-Nov-88, Released 9 dec 88
Status: Rejected, Jan 89 X3J13
+ SUBSEQ-OUT-OF-BOUNDS
29-MAR-88 Version 2
Status: Passed, 1988?
- SUBTYPEP-EMPTY-NIL
Version 1, March 89
Status: => editorial, no cleanup needed
* SUBTYPEP-ENVIRONMENT
Version 1, 2-Jan-89
Status: ** missing writeup ***
+ SUBTYPEP-TOO-VAGUE
Version 4, 7-Oct-88, Released 7 Oct 88
Status: passed, Jan 89 X3J13
- SYMBOL-MACROFLET
Version 1, 30 Sep 88
Synopsis: Add SYMBOL-MACROFLET gives lexical function expansion
Status: withdraw? Please?
+ SYMBOL-MACROLET-DECLARE
Version 2, 9-Dec-88, Released 9 Dec 88
Status: passed, Jan 89 X3J13
!+ SYMBOL-MACROLET-SEMANTICS
Version 5, 30-Nov-88, Released 9 Dec 88
Status: Passed, Jan 89 X3J13
Version 6, 14-Mar-89, released 16-Mar-89
Status: ready for vote
- TAGBODY-CONTENTS
Version 5, 9-Dec-88, Released 9 Dec 88
Comments: "good that this failed, but we still need a clarification"
Status: Failed, Jan 89 X3J13
+ TAILP-NIL
Version 5, 9-Dec-88, Released 12-Dec-88
Synopsis: Operation of TAILP given NIL
Status: passed, Jan 89 X3J13
+ TEST-NOT-IF-NOT
Version 3, 1 Dec 88, Released 9 dec
Version 4, 18-Mar-89
Status: Need new version as amended.
! THE-AMBIGUITY
Version 2, 11-Jan-89, Released 11-Jan-89
Comments: typo, sense wrong
Status: tabled, vote on 2
! TIME-ZONE-NON-INTEGER
Version 1, 13-Mar-89, Released 16-Mar-89
Status: ready for vote
- TRACE-ERROR
Synopsis: TRACE should signal errors if it doesn't understand
Version 1, 20-Jun-88
Comments: is this a cleanup?
Status: withdrawn
- TRACE-FUNCTION-ONLY
Synopsis: extend TRACE to handle other specs
Comment: we don't like it
Status: withdrawn
- TRUENAME-SYNTAX-ONLY
Version 1, 12-Sep-88
Synopsis: when does TRUENAME perform checking?
Comments: other options? leave more vague? Other questions?
Status: => "pathname"?
+* TYPE-OF-UNDERCONSTRAINED
Version 3, 12-Dec-88, Released 12 Dec 88
Comments: Accepted, with amendments
Version 5, 16-Mar-89
Comments: constraints wrong
Status: ** NEED NEW VERSION ***
- TYPE-SPECIFIER-PREDICATE
Synopsis: "Add a new function TYPE-SPECIFIER-P that is true of valid type
specifiers and false of all other Lisp objects. Note that the use of
DEFSTRUCT and DEFTYPE can change the behavior of TYPE-SPECIFIER-P over
time."
Comments: considerable discussion on common lisp mailing list.
Status: probably not
! UNDEFINED-VARIABLES-AND-FUNCTIONS
Synopsis: What happens on an undefined function call, unbound variable ref?
Version 1, 29-Nov-88, Released 11-Jan-89
Comments: Lumping SLOT-UNBOUND in with unbound special variables was a mistake,
as SLOT-UNBOUND is an extension mechanism, not only a safety checking
mechanism. Also there were some wording problems. Gabriel and Gregor
are to submit a revised proposal.
No version arrived.
Status: vote on 1?
+ UNREAD-CHAR-AFTER-PEEK-CHAR
Version 2, 2-Dec-88, Released 12-Dec-88
Status: passed, Jan 89 X3J13
+ VARIABLE-LIST-ASYMMETRY
Version 3, 08-Oct-88, Released 9 Dec 88
Status: passed, Jan 89 X3J13
+ WITH-OUTPUT-TO-STRING-APPEND-STYLE
Version 5, 7-JUN-88
Status: Passed, 1988?
∂18-Mar-89 0216 CL-Cleanup-mailer Issue: REMF-DESTRUCTION-UNSPECIFIED (Version 5)
Received: from Think.COM by SAIL.Stanford.EDU with TCP; 18 Mar 89 02:16:20 PST
Return-Path: <barmar@Think.COM>
Received: from OCCAM.THINK.COM by Think.COM; Fri, 17 Mar 89 15:14:23 EST
Date: Fri, 17 Mar 89 15:14 EST
From: Barry Margolin <barmar@Think.COM>
Subject: Issue: REMF-DESTRUCTION-UNSPECIFIED (Version 5)
To: David A. Moon <Moon@stony-brook.scrc.symbolics.com>
Cc: masinter.pa@xerox.com, kmp@symbolics.com, cl-cleanup@sail.stanford.edu
In-Reply-To: <19890317000217.3.MOON@EUPHRATES.SCRC.Symbolics.COM>
Message-Id: <19890317201410.8.BARMAR@OCCAM.THINK.COM>
Date: Thu, 16 Mar 89 19:02 EST
From: David A. Moon <Moon@stony-brook.scrc.symbolics.com>
Date: Thu, 16 Mar 89 17:22 EST
From: Barry Margolin <barmar@Think.COM>
I would support a version that makes NSUBSTITUTE* be explicitly
specific. I see no reason not to require it to use SETF of CAR or AREF,
as appropriate. Unless someone is working on CAR-coding, I don't think
it precludes any known optimizations.
I'd support that too. In other words, describe NSUBSTITUTE with language
similar to the description of NSUBST.
OK, here goes:
Issue: REMF-DESTRUCTION-UNSPECIFIED
References: (SETF (GET ...) ...), REMPROP, (SETF (GETF ...) ...),
REMF (pp165-167); NREVERSE (p248); DELETE, DELETE-IF,
DELETE-DUPLICATES, NSUBSTITUTE, NSUBSTITUTE-IF (pp254-256);
NCONC, NRECONC (p269); NUNION, NINTERSECTION,
NSET-EXCLUSIVE-OR (pp276-279).
Category: CLARIFICATION/CHANGE
Edit history: 11-Feb-87, Version 1 by Dave Andre (DLA@Symbolics.COM)
29-Oct-87, Version 2 by Pitman (flesh out proposals)
28-Nov-88, Version 3 by Pitman (revised presentation)
29-Nov-88, Version 4 by Pitman (slight editing per DLA)
15-Mar-89, Version 5 by Margolin (amendments discussed in
Hawaii, removed -NOT functions)
17-Mar-89, Version 6 by Margolin (make NSUBSTITUTE* less vague)
Status: For Internal Discussion
Problem Description:
Currently, the exact nature of the side-effect performed by list
modification routines is not specified.
Either the specific modifications allowed should be specified so that
programmers can rely on them and implementors can avoid accidentally
causing problems by introducing well-meaning optimizations, or else
the documentation should explicitly state that the effects are
unspecified so that programmers will not depend on them and
implementors will feel comfortable about doing interesting optimizations.
Proposal (REMF-DESTRUCTION-UNSPECIFIED:EXPLICITLY-VAGUE-EXCEPT-NCONC-AND-NSUBSTITUTE):
[This proposal name is getting way out of hand!]
Clarify that the way in which the destructive behavior of the
operators below is achieved is explicitly vague in a number of ways,
in order to provide individual implementations the necessary
flexibility to do useful optimizations.
(SETF (GETF place indicator) value)
is permitted to either SETF place or to SETF any part, CAR or
CDR, of the top-level list structure held by that place.
(REMF place indicator)
is permitted to either SETF place or to SETF any part, CAR or
CDR, of the top-level list structure held by that place.
(SETF (GET symbol indicator) value)
is constrained to behave exactly the same as
(SETF (GETF (SYMBOL-PLIST symbol) indicator) value).
(REMPROP symbol indicator)
is constrained to behave exactly the same as
(REMF (SYMBOL-PLIST symbol) indicator).
(NREVERSE sequence)
when sequence is a list, is permitted to SETF any part, CAR or
CDR, of the top-level list structure in that sequence.
when sequence is an array is permitted to re-order the elements
of the given sequence in order to produce the resulting array.
(DELETE object sequence ...)
when sequence is a list, is permitted to SETF any part, CAR or
CDR, of the top-level list structure held in that sequence.
when sequence is an array is permitted to change the dimensions
of the array and to slide its elements into new positions without
permuting them to produce the resulting array.
(DELETE-IF test sequence ...)
is constrained to behave exactly like
(DELETE NIL sequence
:TEST #'(LAMBDA (IGNORE ITEM) (FUNCALL test ITEM))
...).
(DELETE-DUPLICATES sequence ...)
when sequence is a list, is permitted to SETF any part, CAR or
CDR, of the top-level list structure held in that sequence.
when sequence is an array is permitted to change the dimensions
of the array and to slide its elements into new positions without
permuting them to produce the resulting array.
(NRECONC list tail)
is constrained to have side-effect behavior equivalent to:
(NCONC (NREVERSE list) tail).
(NUNION list1 list2 ...)
(NINTERSECTION list1 list2 ...)
(NSET-EXCLUSIVE-OR list1 list2 ...)
is permitted to SETF any part, CAR or CDR, of the top-level of
any of the given lists.
Note, however, that since this side-effect is not required,
these functions should still not be used in for-effect-only
positions in portable code.
(NCONC . lists)
is defined using the following recursive relationship:
(NCONC) => NIL
(NCONC NIL . args) == (NCONC . args)
(NCONC arg) => arg
(NCONC arg1 arg2) has the side effect of (RPLACD (LAST arg1) arg2),
and returns arg1
(NCONC arg1 arg2 . args) == (NCONC (NCONC arg1 arg2) . args)
[If a previous cleanup issue prohibited NIL as a non-last argument
then ignore the (NCONC NIL . args) case.]
(NSUBSTITUTE new-object old-object sequence ...)
(NSUBSTITUTE-IF new-object test sequence ...)
is required to SETF any CAR (if SEQUENCE is a list) or VREF (if it's
a vector) of SEQUENCE which is required to be replaced with
NEW-OBJECT. If SEQUENCE is a list, it none of the CDRs of the
top-level list may be modified. These functions, therefore, may be
used in for-effect-only positions in code (some may find this
stylistically distasteful, though).
Note: The above clarifications are not intended as complete functional
descriptions. They are intended to augment (rather than to replace)
other descriptions already in effect.
Test Cases:
For GETF...
(SETQ FOO (LIST 'A 'B 'C 'D 'E 'F)) ==> (A B C D E F)
(SETQ BAR (CDDR FOO)) ==> (C D E F)
(REMF FOO 'C)
BAR ==> ??
In Symbolics Common Lisp, BAR holds (C D E F).
CLtL allows other interpretations. eg, BAR might hold
(C), (NIL), (C NIL) or (C D).
Under this proposal, any of these interpretations (and others as well)
would still be valid
For DELETE...
(SETQ FOO (LIST 'A 'B 'C)) ==> (A B C)
(SETQ BAR (CDR FOO)) ==> (B C)
(SETQ FOO (DELETE 'B FOO)) ==> (A C)
BAR ==> ??
(EQ (CDR FOO) (CAR BAR)) ==> ??
In Symbolics Common Lisp, these last two expressions return ((C)) and T.
Under this proposal, either of these interpretations (and others
as well) would be valid.
For NCONC...
(SETQ FOO (LIST 'A 'B 'C 'D 'E)
BAR (LIST 'F 'G 'H 'I 'J)
BAZ (LIST 'K 'L 'M)) => (K L M)
(SETQ FOO (NCONC FOO BAR BAZ)) => (A B C D E F G H I J K L M)
FOO => (A B C D E F G H I J K L M)
BAR => (F G H I J K L M)
BAZ => (K L M)
(SETQ FOO (LIST 'A 'B 'C 'D 'E)
BAR (LIST 'F 'G 'H 'I 'J)
BAZ (LIST 'K 'L 'M)) => (K L M)
(SETQ FOO (NCONC NIL FOO BAR NIL BAZ)) => (A B C D E F G H I J K L M)
FOO => (A B C D E F G H I J K L M)
BAR => (F G H I J K L M)
BAZ => (K L M)
Rationale:
Implementations already vary widely on their implementation techniques
for these functions. This effectively clarifies the status quo, making
it more clear to programmers what they may rely upon in portable code.
In the case of NCONC, however, the precise definition is useful because
it is what users expect, it is how NCONC has been defined for many
years, and it is how current implementations generally work. It may
not always be the most efficient way (e.g. it may result in invisible
pointers in CDR-coded implementations), but callers of NCONC probably
use it specifically for its precise side effects.
In the case of NSUBSTITUTE, this seems like the only reasonable
implementation mechanism, and there doesn't seem to be a reason not to
guarantee it.
Current Practice:
All valid implementations are believed to comply with the vague
definitions. Symbolics Genera 7.2 and Sun Common Lisp 2.1.3 appear to
conform to the NCONC spec.
Cost to Implementors:
None. This is probably the status quo for most implementors. If there
are any implementations that don't implement NCONC and NSUBSTITUTE as
above (which I doubt) they will have to be changed.
Cost to Users:
This change would not affect programs coded with "good programming
practice". That is, only programs which rely on currently undocumented
features would be in any danger of breaking. In fact, those programs
are already in such danger, and this change to the documentation would
just publicize it. The clarification would -encourage- good programming
practice by warning people to only obey the published contract of the
above-mentioned functions.
There is, however, no automatic technique for making this check for
programs already in error. Bugs due to unexpected side-effects are in
general among the hardest to reckon with.
Cost of Non-Adoption:
Programmers may naively believe there is only one possible or reasonable
implementation of these functions. Some implementors may shy away from
reasonable optimizations out of a paranoid belief that deviating from
some vague, unspoken rules will lead to programmer unrest. Making these
things explicitly vague clarifies the implementor's rights in a way that
permits numerous useful optimizations.
Benefits:
Users would be discouraged from taking advantage of subtle details
of these destructive operations because such details would be explicitly
not guaranteed to be portable.
Implementations can improve performance of many of the above-mentioned
functions when they are not under the constraint to implement them
in a highly constrained fashion. For example, in Symbolics systems,
DELETE of a cdr-coded list could use the implementation primitive
%CHANGE-LIST-TO-CONS rather than RPLACD to avoid creating forwarding
pointers.
Garbage collection effectiveness can also be improved. For example,
all of the destructive operations which remove objects (eg, REMF)
could remove CAR pointers to removed objects which are more volatile
than the list itself, assisting the garbage collector and thereby
improving memory usage and paging performance.
Tightening the definition of NCONC and NSUBSTITUTE permits users to
predict their programs' behavior more precisely.
Non-Benefits:
Users who inadvertently depend on side-effect behavior may be rudely
surprised when moving between implementations.
Compatibility with older Lisp dialects is diminished.
Implementors have less flexibility in implementing NCONC efficiently.
This is true of NSUBSTITUTE, but this is less likely to cause problems.
Performance Impact:
Metering in Symbolics test systems have shown that there are substantial
performance gains to be had by allowing implementations flexibility in
these areas.
In the case of NCONC, this implementation flexibility, and hence
potential performance improvements, is sacrificed.
If anyone ever invents CAR-coding, the required implementation of
NSUBSTITUTE could be a performance hindrance.
Aesthetics:
Most of these functions implement abstract operations. For example,
REMPROP implements an abstract operation on a "property list".
Proper language design should not encourage people to delve below the
level of abstraction into the nitty gritty.
NCONC is a "less abstract" function than the rest of the functions
described above. It is usually used precisely because of the way it
interacts with list implementation. Similarly for NSUBSTITUTE.
Discussion:
Andre's original version of this proposal pushed for explicitly vague
descriptions of these functions' side-effect behavior. He believes
that if users want more predictability from these functions, they
should write private variants that implement whatever predictability
they require.
Pitman originally opposed this position because he weighed portability
a higher concern. Since the original discussion, however, his views on
how to resolve this priority have been refined, and he now believes
that leaving things vague is appropriate. As such, he now supports what
is effectively Andre's original proposal.
Pitman and Andre supported version 4. [I don't know how they feel
about v6 -- Barmar].
Moon supports version 6.
∂18-Mar-89 1708 CL-Cleanup-mailer *DRAFT* Issue: DESTRUCTURING-BIND, v.2
Received: from moon.src.honeywell.com (ALTURA.HONEYWELL.COM) by SAIL.Stanford.EDU with TCP; 18 Mar 89 17:08:07 PST
Return-Path: <alarson@src.honeywell.com>
Received: from pavo.SRC.Honeywell.COM by moon.src.honeywell.com (5.59/smail2.6.3/06-17-88);
Sat, 18 Mar 89 19:07:01 CST id AA09942 for cl-cleanup@sail.stanford.edu
Posted-Date: Sat, 18 Mar 89 19:05:07 CST
Received: by pavo.src.honeywell.com (3.2/SMI-3.2)
id AA20299; Sat, 18 Mar 89 19:05:07 CST
Date: Sat, 18 Mar 89 19:05:07 CST
From: alarson@src.honeywell.com (Aaron Larson)
Message-Id: <8903190105.AA20299@pavo.src.honeywell.com>
To: masinter.pa@Xerox.COM
Cc: cl-cleanup@sail.stanford.edu
In-Reply-To: masinter.pa@Xerox.COM's message of 16 Mar 89 11:46 PST <890316-114911-4982@Xerox>
Subject: *DRAFT* Issue: DESTRUCTURING-BIND, v.2
If the result of evaluating the expression does not match the
destructuring pattern, the consequences are undefined. Implementations
are not required to signal an error in this case, but neither are they
permitted to extend the behavior by defining it to be harmless.
At the risk of getting rpg started again, what does it mean?
∂18-Mar-89 1720 CL-Cleanup-mailer Issue DESCRIBE-UNDERSPECIFIED, v.1
Received: from moon.src.honeywell.com (ALTURA.HONEYWELL.COM) by SAIL.Stanford.EDU with TCP; 18 Mar 89 17:20:52 PST
Return-Path: <alarson@src.honeywell.com>
Received: from pavo.SRC.Honeywell.COM by moon.src.honeywell.com (5.59/smail2.6.3/06-17-88);
Sat, 18 Mar 89 19:19:40 CST id AA10441 for cl-cleanup@SAIL.STANFORD.EDU
Posted-Date: Sat, 18 Mar 89 19:17:51 CST
Received: by pavo.src.honeywell.com (3.2/SMI-3.2)
id AA20309; Sat, 18 Mar 89 19:17:51 CST
Date: Sat, 18 Mar 89 19:17:51 CST
From: alarson@src.honeywell.com (Aaron Larson)
Message-Id: <8903190117.AA20309@pavo.src.honeywell.com>
To: masinter.pa@Xerox.COM
Cc: cl-cleanup@SAIL.STANFORD.EDU
In-Reply-To: masinter.pa@Xerox.COM's message of 16 Mar 89 08:19 PST <890316-082029-3881@Xerox>
Subject: Issue DESCRIBE-UNDERSPECIFIED, v.1
REMARKS:
Methods on DESCRIBE-OBJECT may recursively call DESCRIBE. Indentation,
depth limits, and circularity detection are all taken care of automatically,
provided that each method handles exactly one level of structure and calls
DESCRIBE recursively argument if there are more structural levels.
Something is missing on the last line. Was there supposed to be a
recursivep argument?
∂18-Mar-89 2312 CL-Cleanup-mailer Issue: DEFMACRO-LAMBDA-LIST, v.2
Received: from REAGAN.AI.MIT.EDU by SAIL.Stanford.EDU with TCP; 18 Mar 89 23:12:38 PST
Received: from ISABEL-PERON.AI.MIT.EDU by REAGAN.AI.MIT.EDU via CHAOS with CHAOS-MAIL id 182861; Sun 19-Mar-89 01:25:45 EST
Date: Sun, 19 Mar 89 01:28 EST
From: Richard Mlynarik <Mly@AI.AI.MIT.EDU>
Subject: Issue: DEFMACRO-LAMBDA-LIST, v.2
To: masinter.pa@xerox.com, cl-cleanup@sail.stanford.edu
In-Reply-To: <890317-195034-3172@Xerox>
Message-ID: <19890319062819.3.MLY@ISABEL-PERON.AI.MIT.EDU>
1. a. Specify that &BODY may appear at any level of a DEFMACRO lambda list.
b. Specify that &WHOLE may only appear at any level of a DEFMACRO
lambda list. At inner levels, the &WHOLE variable is bound to
``May only appear at any level'' sounds like a control-Y bug.
c. Specify that &ENVIRONMENT may only appear at the top level of a
DEFMACRO lambda list.
Something else which needs to be clarified is where the &ENVIRONMENT
keyword may appear.
Which of the following are legal?
1. (defmacro foo (&whole w &environment e a b) ...)
2. (defmacro foo (&environment e &whole w a b) ...)
3. (defmacro foo (&whole w a b &environment e) ...)
4. (defmacro foo (&whole w a &environment e b) ...)
I'd like to say 1,2 and 3 only, even though case 2 would require some
modification of the ``first in the lambda-list'' terminology.
∂19-Mar-89 1058 CL-Cleanup-mailer Issue: HASH-TABLE-ACCESS (version 2)
Received: from moon.src.honeywell.com (ALTURA.HONEYWELL.COM) by SAIL.Stanford.EDU with TCP; 19 Mar 89 10:58:19 PST
Return-Path: <alarson@src.honeywell.com>
Received: from pavo.SRC.Honeywell.COM by moon.src.honeywell.com (5.59/smail2.6.3/06-17-88);
Sun, 19 Mar 89 12:57:12 CST id AA11401 for cl-cleanup@sail.stanford.edu
Posted-Date: Sun, 19 Mar 89 12:55:24 CST
Received: by pavo.src.honeywell.com (3.2/SMI-3.2)
id AA20779; Sun, 19 Mar 89 12:55:24 CST
Date: Sun, 19 Mar 89 12:55:24 CST
From: alarson@src.honeywell.com (Aaron Larson)
Message-Id: <8903191855.AA20779@pavo.src.honeywell.com>
To: masinter.pa@Xerox.COM
Cc: cl-cleanup@sail.stanford.edu
In-Reply-To: masinter.pa@Xerox.COM's message of 16 Mar 89 22:51 PST <890316-225136-6875@Xerox>
Subject: Issue: HASH-TABLE-ACCESS (version 2)
HASH-TABLE-REHASH-SIZE hash-table
Returns the current rehash size of a hash table.
Two minor nits, first the wording should say "of the hash-table", and
secondly the results of passing in a non hash table should be described,
e.g. signals an error, or is undefined. I think having portable access to
the HASH-TABLE-TEST is quite important, I would hate to loose the chance to
get that because of the other functions, but I guess that an ammendment on
the floor could remove the ones people have trouble with.
∂20-Mar-89 1229 CL-Cleanup-mailer Re: Issue: PRETTY-PRINT-INTERFACE (version 3)
Received: from multimax.encore.com by SAIL.Stanford.EDU with TCP; 20 Mar 89 12:29:22 PST
Received: from mist.encore.COM by multimax.encore.com with SMTP (5.61/25-eef)
id AA00470; Mon, 20 Mar 89 10:13:54 -0500
Received: from localhost by mist. (4.0/SMI-4.0)
id AA01358; Mon, 20 Mar 89 10:15:47 EST
Message-Id: <8903201515.AA01358@mist.>
To: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Cc: cl-cleanup@sail.stanford.edu
Subject: Re: Issue: PRETTY-PRINT-INTERFACE (version 3)
In-Reply-To: Your message of Sat, 18 Mar 89 01:32:00 -0500.
<19890318063223.0.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Mon, 20 Mar 89 10:15:45 EST
From: Dan L. Pierson <pierson@mist.encore.com>
Date: Sat, 18 Mar 89 01:32 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
I could not find any specification of the units of measurement for
*PRINT-RIGHT-MARGIN*, *DEFAULT-RIGHT-MARGIN*, *PRINT-MISER-WIDTH*,
indentation, and tabulation. It's not even clear that margins,
indentation, and tabulation can't be measured in three different
units. Analysis of the examples suggests that the units are
assumed to be characters and all characters are assumed to be the
same width. This is not an implementation-independent assumption.
In any case the proposal has to be specific about the units. I
would prefer something that seamlessly accomodates variable-width
characters, but don't have enough experience with pretty-printers
to propose anything myself.
I think that all three clearly have to be in the same units; the
writeup should be changed to specify this. After thinking about it
for a while, it's not clear that the exact unit matters much as long
as it's not to small. Pixels are too small; "n"'s or "m"'s aren't.
Personally I'd suggest an "m" as the standard unit.
Other than that, I don't think the propsal has terrible problems with
variable width (even kerned) fonts because most indentation is done
relative to the position of the start of another word. This common
case can be handled with arbitrary precision; a variable width font
implementation would presumably indent to the exact pixel position of
the relevant character (how would that be expressed in Postscript?).
Of course parts of the proposal won't work for right-to-left or
top-to-bottom languages. I think that rejecting the proposal because
of that would be ridiculous.
∂20-Mar-89 1236 CL-Cleanup-mailer Re: Issue: PRETTY-PRINT-INTERFACE (version 3)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 20 Mar 89 12:36:46 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 561205; Mon 20-Mar-89 15:35:05 EST
Date: Mon, 20 Mar 89 15:34 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: Issue: PRETTY-PRINT-INTERFACE (version 3)
To: Dan L. Pierson <pierson@mist.encore.com>
cc: cl-cleanup@SAIL.STANFORD.EDU, disk@wheaties.ai.mit.edu
In-Reply-To: <8903201515.AA01358@mist.>
Message-ID: <19890320203457.2.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Mon, 20 Mar 89 10:15:45 EST
From: Dan L. Pierson <pierson@mist.encore.com>
Date: Sat, 18 Mar 89 01:32 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
I could not find any specification of the units of measurement for
*PRINT-RIGHT-MARGIN*, *DEFAULT-RIGHT-MARGIN*, *PRINT-MISER-WIDTH*,
indentation, and tabulation.
I think that all three clearly have to be in the same units; the
writeup should be changed to specify this. After thinking about it
for a while, it's not clear that the exact unit matters much as long
as it's not to small. Pixels are too small; "n"'s or "m"'s aren't.
Personally I'd suggest an "m" as the standard unit.
I don't see anything wrong with that, although I can't claim to be an
expert in this area.
Other than that, I don't think the propsal has terrible problems with
variable width (even kerned) fonts because most indentation is done
relative to the position of the start of another word. This common
case can be handled with arbitrary precision; a variable width font
implementation would presumably indent to the exact pixel position of
the relevant character (how would that be expressed in Postscript?).
I think what you're saying is that the argument to LOGICAL-BLOCK-INDENT
(or ~I) is almost always zero? In the examples given in version 1
of the proposal, zero is in the majority, there are also two 1's and
a 2. I didn't find any cases where the number given to ~I seemed to
be intended to correspond to the number of characters in some word.
There might need to be a style suggestion for writers of pretty print
methods telling them to use relative indentation instead of counting
characters. Given that, your suggestion sounds plausible to me.
∂20-Mar-89 1241 CL-Cleanup-mailer Issue: COMPLEX-RATIONAL-RESULT (version 1)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 20 Mar 89 12:40:41 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 560964; Mon 20-Mar-89 11:41:43 EST
Date: Mon, 20 Mar 89 11:41 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: COMPLEX-RATIONAL-RESULT (version 1)
To: CL-Cleanup@sail.stanford.edu
cc: chapman%aitg.DEC@decwrl.dec.com
Message-ID: <19890320164136.0.MOON@EUPHRATES.SCRC.Symbolics.COM>
This issue came up while reviewing section 2.2 of the draft standard.
Does anyone object if I mail this to X3J13 and bring it up at the
March meeting? I couldn't find any sign that it has already been addressed.
Issue: COMPLEX-RATIONAL-RESULT
References: CLtL p.203
Category: CLARIFICATION
Edit history: Version 1, 20-Mar-89, by Moon
Problem description:
Referring to irrational and transcendental functions, CLtL says:
When the arguments to a function in this section are all rational and
the true mathematical result is also (mathematically) rational, then
unless otherwise noted an implementation is free to return either an
accurate result of type rational or a single-precision floating-point
approximation. If the arguments are all rational but the result cannot
be expressed as a rational number, then a single-precision
floating-point approximation is always returned.
Referring to EXPT, CLtL says:
If the base-number is of type RATIONAL and the power-number is an
INTEGER, the calculation will be exact and the result will be of
type RATIONAL; otherwise a floating-point approximation may result.
What about arguments of type (complex rational)?
Proposal (COMPLEX-RATIONAL-RESULT:EXTEND):
Extend the paragraph quoted above to cover the components of complex
numbers. For (complex rational) arguments, a mathematically rational
result can be rational, (complex rational), or (complex float) at the
discretion of the implementation. For EXPT of a (complex rational) to
an integer power, the calculation must be exact and the result will
be rational or (complex rational).
Examples:
(log #c(-16 16) #c(2 2)) => 3 or approximately #c(3.0 0.0)
(expt #c(2 2) 3) => #c(-16 16)
(expt #c(2 2) 4) => -64
Rationale:
This seems most consistent with the treatment of real numbers.
Current practice:
Symbolics Genera 7.4 returns a (complex float) for the first example
and returns the specified answers for the second and third examples.
Other implementations were not surveyed.
Cost to Implementors:
Only EXPT would have to change, since the type of the other results
is at the discretion of the implementation.
Cost to Users:
Probably none, but it is hard to predict.
Cost of non-adoption:
Slightly less self-consistent language.
Performance impact:
None of any significance.
Benefits/Esthetics:
More self-consistent language.
Discussion:
None.
∂20-Mar-89 1241 CL-Cleanup-mailer Issue: HASH-TABLE-SIZE (version 1)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 20 Mar 89 12:41:39 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 560978; Mon 20-Mar-89 11:55:18 EST
Date: Mon, 20 Mar 89 11:55 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: HASH-TABLE-SIZE (version 1)
To: CL-Cleanup@sail.stanford.edu
cc: chapman%aitg.DEC@decwrl.dec.com
Message-ID: <19890320165503.1.MOON@EUPHRATES.SCRC.Symbolics.COM>
This issue came up while reviewing section 2.2 of the draft standard.
Does anyone object if I mail this to X3J13 and bring it up at the
March meeting? I couldn't find any sign that it has already been addressed.
Issue: HASH-TABLE-SIZE
References: CLtL p.283
Category: CLARIFICATION
Edit history: Version 1, 20-Mar-89, by Moon
Problem description:
CLtL contradicts itself on the meaning of the :SIZE argument to
MAKE-HASH-TABLE. At the top of p.283, it says that the size is "the
maximum number of entries it can hold. Usually the actual capacity of
the table is somewhat less." At the bottom of the page it says "this
argument serves as a hint to the implementation of approximately how
many entries you intend to store." So does the :SIZE intended to be the
actual capacity of the table, or the amount of storage allocated to hold
the table. For example, if the implementation of hash tables is
designed for a loading of 65%, and the user specifies :SIZE 100, does
the table returned have space allocated for 100 entries, so that it
overflows and becomes bigger when 65 entries are inserted, or does the
table have space allocated for 154 entries, so that it overflows and
becomes bigger when 100 entries are inserted?
Proposal (HASH-TABLE-SIZE:INTENDED-ENTRIES):
Believe the bottom of p.283 rather than the top. The :SIZE argument
is approximately the number of entries that can be inserted without
the table having to grow.
Rationale:
The bottom of p.283 is user-oriented, the top is implementation-oriented.
User-oriented seems more appropriate.
Current practice:
Symbolics Genera 7.4 adheres to HASH-TABLE-SIZE:INTENDED-ENTRIES.
Other implementations were not surveyed.
Cost to Implementors:
At worst adding a multiplication to MAKE-HASH-TABLE.
Cost to Users:
Probably none, but it is hard to predict.
Cost of non-adoption:
Implementations will probably vary in which of the two interpretations
they believe. The language standard will not be self-consistent.
Performance impact:
None of any significance.
Benefits/Esthetics:
More self-consistent language.
Discussion:
None.
∂20-Mar-89 1242 CL-Cleanup-mailer Issue: PATHNAME-COMPONENT-VALUE (version 1)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 20 Mar 89 12:41:44 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 561033; Mon 20-Mar-89 13:04:18 EST
Date: Mon, 20 Mar 89 13:04 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: PATHNAME-COMPONENT-VALUE (version 1)
To: CL-Cleanup@sail.stanford.edu
cc: chapman%aitg.DEC@decwrl.dec.com
Message-ID: <19890320180405.2.MOON@EUPHRATES.SCRC.Symbolics.COM>
This issue came up while reviewing section 2.2 of the draft standard.
Does anyone object if I mail this to X3J13 and bring it up at the
March meeting? I couldn't find any sign that it has already been addressed.
Issue: PATHNAME-COMPONENT-VALUE
Related Issues:PATHNAME-CANONICAL-TYPE,
PATHNAME-SUBDIRECTORY-LIST,
PATHNAME-UNSPECIFIC-COMPONENT,
PATHNAME-WILD
References: CLtL pp.410-3
Category: CLARIFICATION and CHANGE
Edit history: Version 1, 20-Mar-89, by Moon
Problem description:
CLtL is overly restrictive on the possible values for pathname components.
These restrictions are described in a funny way that makes it unclear
whether they are requirements, guidelines, or just an example.
The restrictions are not all written down in one place, but they appear
to be as follows:
Host nil, :wild, string, or list of strings
Device nil, :wild, string, or something else ("structured")
Directory nil, :wild, string, or something else ("structured")
Name nil, :wild, string, or something else ("structured")
Type nil, :wild, or string
Version nil, :wild, :newest, positive integer, implementation
dependent symbol, or implementation-dependent integer
less than or equal to zero. Suggestions include :oldest,
:previous, :installed, 0, and -1.
PATHNAME-UNSPECIFIC-COMPONENT:NEW-TOKEN allowed implementations to
allow any component to be :UNSPECIFIC. This has been voted in.
PATHNAME-SUBDIRECTORY-LIST proposes a list of strings and keyword
symbols for the directory component.
PATHNAME-CANONICAL-TYPE proposes some new operations but does not
change the possible values of the type component.
PATHNAME-WILD proposes a portable way to test for implementation
dependent component values that indicate wildcard matching. It
does not change the possible values of any component.
Proposal (PATHNAME-COMPONENT-VALUE:SPECIFY):
The points of the proposal have been numbered to facilitate
amendments to remove or modify individual points.
When examining pathname components, conforming programs must be
prepared to encounter any of the following values:
1. Any component can be NIL, which means the component has not
been specified.
2. Any component can be :UNSPECIFIC, which means the component has
no meaning in this particular pathname.
3. Any component can be :WILD, which matches any component value.
Wild pathnames can be used with DIRECTORY but not with OPEN.
4. The host, device, directory, name, and type can be strings.
5. The host and device can be a list, a structure, or a
standard-object at the discretion of the implementation.
6. The directory can be a list of strings and symbols as detailed in
PATHNAME-SUBDIRECTORY-LIST (this assumes that it passes.)
7. The version can be any symbol or any integer. The symbol :NEWEST
refers to the largest version number that already exists in the file
system when reading, overwriting, appending, superseding, or directory
listing an existing file, and refers to the smallest version number
greater than any existing version number when creating a new file.
When constructing a pathname from components, conforming programs
must follow these rules:
11. Any component can be NIL. NIL in the host may mean a default host
rather than an actual NIL in some implementations.
12. Any component can be :WILD, which matches any component value.
Wild pathnames can be used with DIRECTORY but not with OPEN.
13. The host, device, directory, name, and type can be strings.
14. The directory can be a list of strings and symbols as detailed in
PATHNAME-SUBDIRECTORY-LIST (this assumes that it passes.)
15. The version can be :NEWEST.
16. Any component can be taken from the corresponding component
of another pathname on the same host and device.
17. An implementation might support other values for some
components, but a portable program cannot use those values.
An implementation might allow values to be transferred between
pathnames on different hosts or different devices, but a portable
program cannot rely on that.
A conforming program can use implementation-dependent values
but this can make it non-portable, for example, it might work
only with Unix file systems.
18. It is suggested, but not required, that implementations use
positive integers starting at 1 as version numbers, recognize
the symbol :oldest to designate the smallest existing version
number, and use keyword symbols for other special versions.
Consequences:
The changes relative to CLtL plus PATHNAME-UNSPECIFIC-COMPONENT
are as follows:
The definition of "structured" component is restricted to lists,
structures, and standard-objects, rather than allowing any object
whatsoever.
"Structured" hosts are allowed, a generalization of CLtL's list
of strings.
"Structured" directories are replaced by PATHNAME-SUBDIRECTORY-LIST.
"Structured" names are forbidden.
The difference between what component values a program can depend
on being able to use, versus what component values a program must
be prepared to encounter, is clarified.
Rationale:
This should make it easier to write portable programs that deal with
pathnames and make it easier for implementors by clarifying the
framework into which they must fit. Also it should make it easier
to write the Common Lisp language specification by resolving some
things that were unclear about the status quo.
Adding "structured" hosts conforms to current practice.
Substituting a default host for NIL conforms to current practice
in implementations that require all pathnames to have a specific host.
Removing "structured" names should improve portability without causing
any harm, assuming no implementation uses structured names. This will
improve portability by allowing programs to do string manipulation on
names, although such programs still have to be careful since the valid
characters and maximum length of a name are implementation-dependent.
Disallowing transferral of nonstandard component values between
different hosts or different devices allows implementations to support
multiple incompatible file systems.
Current practice:
All versions of Symbolics Genera violate CLtL in the matter of hosts,
since it uses standard-objects as the host component. Genera deviates
slightly from PATHNAME-SUBDIRECTORY-LIST, but otherwise conforms to
PATHNAME-COMPONENT-VALUE:SPECIFY.
Other implementations were not surveyed.
This proposal assumes that no current or planned implementation
uses structured names, not even for wildcards.
Cost to Implementors:
Most implementations already conform, except for the changes required
by PATHNAME-UNSPECIFIC-COMPONENT and PATHNAME-SUBDIRECTORY-LIST, so
the cost of this proposal itself should be minimal. It is conceivable
that an implementation may exist that has to change its pathname
representation, for example one that uses numbers as structured devices.
Cost to Users:
None.
Cost of non-adoption:
Pathnames will continue to be a poorly specified part of the language.
Performance impact:
None of any significance.
Benefits/Esthetics:
The boundary between the specified behavior of pathnames and the
implementation-dependent behavior of pathnames will be more clear.
Discussion:
None.
∂20-Mar-89 1241 CL-Cleanup-mailer Issue: COMMON-TYPE (version 1)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 20 Mar 89 12:40:49 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 560953; Mon 20-Mar-89 11:24:20 EST
Date: Mon, 20 Mar 89 11:24 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: COMMON-TYPE (version 1)
To: CL-Cleanup@sail.stanford.edu
cc: chapman%aitg.DEC@decwrl.dec.com
Message-ID: <19890320162410.9.MOON@EUPHRATES.SCRC.Symbolics.COM>
This issue came up while reviewing section 2.2 of the draft standard.
Does anyone object if I mail this to X3J13 and bring it up at the
March meeting? I couldn't find any sign that it has already been addressed.
Issue: COMMON-TYPE
References: CLtL p.35, p.76
Category: CHANGE
Edit history: Version 1, 20-Mar-89, by Moon
Problem description:
The type COMMON is defined in a very peculiar way and does not seem to
be useful for anything. It can be extended by users using DEFSTRUCT,
but not DEFTYPE nor DEFCLASS, but it cannot be extended by implementations.
Whether certain types such as NUMBER and ARRAY are subtypes of COMMON
is implementation-dependent. The goal of having the COMMON type was
probably to improve portability, but it is unclear how it could actually
be used in that way.
Proposal (COMMON-TYPE:REMOVE):
Remove COMMON and COMMONP from the language.
Rationale:
Keeping the definition of COMMON accurate in the new specification, in
the face of changes elsewhere in the language such as the introduction
of CLOS and the possible introduction of character registries, is
difficult when no one is sure what COMMON is for. If no one uses COMMON,
it would be less work to just get rid of it.
Current practice:
Every implementation probably implements COMMON. Moon has never seen it
used except in a program to test whether its implementation matched CLtL.
Cost to Implementors:
None.
Cost to Users:
None unless they are actually using COMMON.
Cost of non-adoption:
Implementors would have to maintain COMMON. Users would have to try to
understand it, or figure out that they didn't care about it.
Performance impact:
None.
Benefits:
Simpler language.
Esthetics:
Simpler language.
Discussion:
None.
∂20-Mar-89 1325 CL-Cleanup-mailer Re: Issue: LOAD-OBJECTS (Version 3)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 20 Mar 89 13:24:54 PST
Received: from Semillon.ms by ArpaGateway.ms ; 20 MAR 89 13:17:33 PST
Date: 20 Mar 89 13:16 PST
From: Danny Bobrow <Bobrow.pa@Xerox.COM>
Subject: Re: Issue: LOAD-OBJECTS (Version 3)
In-reply-to: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>'s message
of Sat, 18 Mar 89 01:50 EST
To: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
cc: Sandra J Loosemore <sandra%defun@cs.utah.edu>, Richard P. Gabriel
<rpg@lucid.com>, CL-Cleanup@sail.stanford.edu,
CL-Compiler@sail.stanford.edu, Common-Lisp-Object-System@sail.stanford.edu
Message-ID: <890320-131733-6488@Xerox>
MAKE-LOAD-FORM-USING-SLOTS is too easy to confuse with
SLOT-VALUE-USING-CLASS. MAKE-LOAD-FORM-FROM-SLOTS is better,
except for form/from dyslexia. MAKE-LOAD-FORM-FOR-SLOTS ?
How about MAKE-LOAD-FORM-SAVING-SLOTS
danny
∂20-Mar-89 1415 CL-Cleanup-mailer Re: Issue: PRETTY-PRINT-INTERFACE (version 3)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 20 Mar 89 14:15:08 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 561357; Mon 20-Mar-89 17:13:50 EST
Date: Mon, 20 Mar 89 17:13 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: Issue: PRETTY-PRINT-INTERFACE (version 3)
To: Dan L. Pierson <pierson@mist.encore.com>
cc: cl-cleanup@SAIL.STANFORD.EDU, dick@wheaties.ai.mit.edu
In-Reply-To: <8903201515.AA01358@mist.>
Supersedes: <19890320203457.2.MOON@EUPHRATES.SCRC.Symbolics.COM>
Comments: Resend after correcting misspelling in Dick Waters' mailbox name.
Message-ID: <19890320221342.0.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Mon, 20 Mar 89 10:15:45 EST
From: Dan L. Pierson <pierson@mist.encore.com>
Date: Sat, 18 Mar 89 01:32 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
I could not find any specification of the units of measurement for
*PRINT-RIGHT-MARGIN*, *DEFAULT-RIGHT-MARGIN*, *PRINT-MISER-WIDTH*,
indentation, and tabulation.
I think that all three clearly have to be in the same units; the
writeup should be changed to specify this. After thinking about it
for a while, it's not clear that the exact unit matters much as long
as it's not to small. Pixels are too small; "n"'s or "m"'s aren't.
Personally I'd suggest an "m" as the standard unit.
I don't see anything wrong with that, although I can't claim to be an
expert in this area.
Other than that, I don't think the propsal has terrible problems with
variable width (even kerned) fonts because most indentation is done
relative to the position of the start of another word. This common
case can be handled with arbitrary precision; a variable width font
implementation would presumably indent to the exact pixel position of
the relevant character (how would that be expressed in Postscript?).
I think what you're saying is that the argument to LOGICAL-BLOCK-INDENT
(or ~I) is almost always zero? In the examples given in version 1
of the proposal, zero is in the majority, there are also two 1's and
a 2. I didn't find any cases where the number given to ~I seemed to
be intended to correspond to the number of characters in some word.
There might need to be a style suggestion for writers of pretty print
methods telling them to use relative indentation instead of counting
characters. Given that, your suggestion sounds plausible to me.
∂20-Mar-89 1427 CL-Cleanup-mailer Re: Issue: LOAD-OBJECTS (Version 3)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 20 Mar 89 14:27:09 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 561368; Mon 20-Mar-89 17:23:27 EST
Date: Mon, 20 Mar 89 17:23 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: Issue: LOAD-OBJECTS (Version 3)
To: Danny Bobrow <Bobrow.pa@XEROX.COM>
cc: Sandra J Loosemore <sandra%defun@cs.utah.edu>, Richard P. Gabriel <rpg@lucid.com>,
CL-Cleanup@SAIL.STANFORD.EDU, CL-Compiler@SAIL.STANFORD.EDU, Common-Lisp-Object-System@SAIL.STANFORD.EDU
In-Reply-To: <890320-131733-6488@Xerox>
Message-ID: <19890320222313.1.MOON@EUPHRATES.SCRC.Symbolics.COM>
Line-fold: No
Date: 20 Mar 89 13:16 PST
From: Danny Bobrow <Bobrow.pa@Xerox.COM>
MAKE-LOAD-FORM-USING-SLOTS is too easy to confuse with
SLOT-VALUE-USING-CLASS. MAKE-LOAD-FORM-FROM-SLOTS is better,
except for form/from dyslexia. MAKE-LOAD-FORM-FOR-SLOTS ?
How about MAKE-LOAD-FORM-SAVING-SLOTS
I like that name.
∂20-Mar-89 1437 CL-Cleanup-mailer Issue: COMMON-TYPE (version 1)
Received: from Think.COM by SAIL.Stanford.EDU with TCP; 20 Mar 89 14:36:39 PST
Received: from fafnir.think.com by Think.COM; Mon, 20 Mar 89 17:27:04 EST
Return-Path: <gls@Think.COM>
Received: from verdi.think.com by fafnir.think.com; Mon, 20 Mar 89 17:28:00 EST
Received: by verdi.think.com; Mon, 20 Mar 89 17:24:46 EST
Date: Mon, 20 Mar 89 17:24:46 EST
From: Guy Steele <gls@Think.COM>
Message-Id: <8903202224.AA19319@verdi.think.com>
To: Moon@stony-brook.scrc.symbolics.com
Cc: CL-Cleanup@sail.stanford.edu, chapman%aitg.DEC@decwrl.dec.com
In-Reply-To: David A. Moon's message of Mon, 20 Mar 89 11:24 EST <19890320162410.9.MOON@EUPHRATES.SCRC.Symbolics.COM>
Subject: Issue: COMMON-TYPE (version 1)
I support COMMON-TYPE:REMOVE.
∂20-Mar-89 1438 CL-Cleanup-mailer Issue: COMMON-TYPE (version 1)
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 20 Mar 89 14:38:37 PST
Received: from blacksox ([192.9.201.39]) by heavens-gate.lucid.com id AA05260g; Mon, 20 Mar 89 14:33:18 PST
Received: by blacksox id AA00779g; Mon, 20 Mar 89 14:38:08 PST
Date: Mon, 20 Mar 89 14:38:08 PST
From: Eric Benson <eb@lucid.com>
Message-Id: <8903202238.AA00779@blacksox>
To: Moon@STONY-BROOK.SCRC.Symbolics.COM
Cc: CL-Cleanup@sail.stanford.edu, chapman%aitg.DEC@decwrl.dec.com
In-Reply-To: David A. Moon's message of Mon, 20 Mar 89 11:24 EST <19890320162410.9.MOON@EUPHRATES.SCRC.Symbolics.COM>
Subject: Issue: COMMON-TYPE (version 1)
Yes, yes, yes. COMMON is useless. I'm sure Guy thought it would be
useful, but it isn't. Burn it. It has not survived the test of time.
∂20-Mar-89 1507 CL-Cleanup-mailer Issue: COMPLEX-RATIONAL-RESULT (version 1)
Received: from Think.COM by SAIL.Stanford.EDU with TCP; 20 Mar 89 15:06:39 PST
Received: from fafnir.think.com by Think.COM; Mon, 20 Mar 89 17:29:50 EST
Return-Path: <gls@Think.COM>
Received: from verdi.think.com by fafnir.think.com; Mon, 20 Mar 89 17:30:06 EST
Received: by verdi.think.com; Mon, 20 Mar 89 17:26:47 EST
Date: Mon, 20 Mar 89 17:26:47 EST
From: Guy Steele <gls@Think.COM>
Message-Id: <8903202226.AA19323@verdi.think.com>
To: Moon@stony-brook.scrc.symbolics.com
Cc: CL-Cleanup@sail.stanford.edu, chapman%aitg.DEC@decwrl.dec.com
In-Reply-To: David A. Moon's message of Mon, 20 Mar 89 11:41 EST <19890320164136.0.MOON@EUPHRATES.SCRC.Symbolics.COM>
Subject: Issue: COMPLEX-RATIONAL-RESULT (version 1)
I support COMPLEX-RATIONAL-RESULT:EXTEND.
∂20-Mar-89 1512 CL-Cleanup-mailer Issue: HASH-TABLE-SIZE (version 1)
Received: from Think.COM by SAIL.Stanford.EDU with TCP; 20 Mar 89 15:10:34 PST
Received: from fafnir.think.com by Think.COM; Mon, 20 Mar 89 17:31:49 EST
Return-Path: <gls@Think.COM>
Received: from verdi.think.com by fafnir.think.com; Mon, 20 Mar 89 17:31:12 EST
Received: by verdi.think.com; Mon, 20 Mar 89 17:27:56 EST
Date: Mon, 20 Mar 89 17:27:56 EST
From: Guy Steele <gls@Think.COM>
Message-Id: <8903202227.AA19331@verdi.think.com>
To: Moon@stony-brook.scrc.symbolics.com
Cc: CL-Cleanup@sail.stanford.edu, chapman%aitg.DEC@decwrl.dec.com
In-Reply-To: David A. Moon's message of Mon, 20 Mar 89 11:55 EST <19890320165503.1.MOON@EUPHRATES.SCRC.Symbolics.COM>
Subject: Issue: HASH-TABLE-SIZE (version 1)
I support HASH-TABLE-SIZE:INTENDED-ENTRIES.
∂20-Mar-89 1556 CL-Cleanup-mailer Issue: PRETTY-PRINT-INTERFACE (version 3)
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 20 Mar 89 15:55:52 PST
Received: from wheat-chex.ai.mit.edu by life.ai.mit.edu; Mon, 20 Mar 89 18:54:57 EST
Received: from localhost by wheat-chex.ai.mit.edu; Mon, 20 Mar 89 18:54:55 EST
Date: Mon, 20 Mar 89 18:54:55 EST
From: dick@wheaties.ai.mit.edu
Message-Id: <8903202354.AA04220@wheat-chex.ai.mit.edu>
To: David A. Moon <Moon@stony-brook.scrc.symbolics.com>
Cc: gls@think.com, cl-cleanup@sail.stanford.edu, dick@wheaties.ai.mit.edu
Subject: Issue: PRETTY-PRINT-INTERFACE (version 3)
RE: your recent comments.
(1) Clearly, the right statements about length units need to be put in
the proposal. A note advising programmers to use explicit lengths as
little as possible also sounds like a good idea.
(2) I agree that it was a severe error to omit the funcional interface.
However, I also think it would be a severe error to omit the format interface.
(3) I understand why you would like to have define-print-dispatch
merged with the CLOS stuff. I will look into that. (Can you
remind me of the issue of SIGPLAN notices that CLOS was described
in? Is that accurate?) However, I think there may be problems.
First, although not particularly shown in the examples, I have
found very elaborate type specifies for printing things (e.g.,
including satisfies clauses) to be quite useful. In the proposal
note the use of the specifier (CONS (AND SYMBOL (SATISFIES FBOUNDP))).
Also note the use of priorities to disambiguate between overlapping
type specifiers. This is very important to get propper
defaulting---i.e. specifying how to print lists in general as well
as particular special forms. Maybe some inheretence things can
make that work in CLOS, but it is not clear to me.
Finally although it can certainly work, passing style of
printing arguments around does not appeal to me anywhere near as
much as multiple dispatch tables, because
when you write your first style, you have to set things up to
allow for more styles even if you never have more styles, or else
face a lot of work when you make a second style. It is also not
clear how this would all fit in with having a standard predefined
style that users can modify as they wish.
It seems to me that the pretty printer and CLOS just do not have
the same idea of what an object is, and that while CLOS primarily
has a quasi-static association of methods to objects, the pretty
printer wants to support rapid wholesale change. Given these
differences, unification may not work as well as one might hope.
(4) Your suggestions for improving the functional interface basically
sound good to me, however I differ slightly with a couple of them.
Combining the :stream and :var sounds like a good idea.
However, The :arg argument is not mandatory. It is not used in the
second example I sent around with the functional interface proposal.
I think that making :prefix, :per-line-prefix, and :suffix functions
is overkill. One can always use #. after all.
Changing the name of :from-start and :from-position and the argument
sounds fine to me.
note that ~/tabular-style/ etc. uses the format interface for
calling a function. Therefore it has already been implicitly
stated that tabular-style, fill-style, and linear-style, are
functions and what their arguments are. The definition of the
function linear-style is given as an example, and fill-style is
used as a function in another example in the original proposal.
Nevertheless, the functional interface part should note that they
are functions.
∂20-Mar-89 1605 CL-Cleanup-mailer Issue: FIXNUM-NON-PORTABLE, v.5
Received: from Think.COM by SAIL.Stanford.EDU with TCP; 20 Mar 89 16:04:01 PST
Received: from fafnir.think.com by Think.COM; Mon, 20 Mar 89 11:47:53 EST
Return-Path: <gls@Think.COM>
Received: from verdi.think.com by fafnir.think.com; Mon, 20 Mar 89 11:48:52 EST
Received: by verdi.think.com; Mon, 20 Mar 89 11:45:31 EST
Date: Mon, 20 Mar 89 11:45:31 EST
From: Guy Steele <gls@Think.COM>
Message-Id: <8903201645.AA17143@verdi.think.com>
To: Moon@stony-brook.scrc.symbolics.com
Cc: masinter.pa@xerox.com, cl-cleanup@sail.stanford.edu
In-Reply-To: David A. Moon's message of Fri, 17 Mar 89 19:53 EST <19890318005344.5.MOON@EUPHRATES.SCRC.Symbolics.COM>
Subject: Issue: FIXNUM-NON-PORTABLE, v.5
Date: Fri, 17 Mar 89 19:53 EST
From: David A. Moon <Moon@stony-brook.scrc.symbolics.com>
Date: 16 Mar 89 21:51 PST
From: masinter.pa@Xerox.COM
This is my rewrite to capture the 'intent' of the amendment
at the January X3J13. I say 'intent' because the relation
between MOST-POSITIVE-FIXNUM (which is an inclusive bound)
and ARRAY-DIMENSION-LIMIT (which is an exclusive bound) is not
> but rather (>= MOST-POSITIVE-FIXNUM (1- ARRAY-DIMENSION-LIMIT)).
No, the amendment was (<= ARRAY-DIMENSION-LIMIT MOST-POSITIVE-FIXNUM),
and this was not a mistake nor an off-by-one error. What you've
put in the proposal here is incorrect, I think. I think it was
fully intended that not only every valid array index and every
array dimension, but also array-dimension-limit itself would be
a fixnum. Someone might want to write an arithmetic iteration
whose upper bound was array-dimension-limit.
I agree with Moon's observations and assessment; this was my understanding
of the amendment.
Pascal-type languages have had no end of grief because iteration counters
take on "invalid" (read "non-fixnum" here and you'll get the idea) values
at the end of the last iteration.
--Guy
∂20-Mar-89 1841 CL-Cleanup-mailer Issue: PRETTY-PRINT-INTERFACE (version 3)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 20 Mar 89 18:41:21 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 561599; Mon 20-Mar-89 21:39:43 EST
Date: Mon, 20 Mar 89 21:39 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: PRETTY-PRINT-INTERFACE (version 3)
To: dick@wheaties.ai.mit.edu
cc: gls@think.com, cl-cleanup@SAIL.STANFORD.EDU
In-Reply-To: <8903202354.AA04220@wheat-chex.ai.mit.edu>
Message-ID: <19890321023936.2.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Mon, 20 Mar 89 18:54:55 EST
From: dick@wheaties.ai.mit.edu
....
(Can you
remind me of the issue of SIGPLAN notices that CLOS was described
in? Is that accurate?)
SIGPlan Notices (ISSN 0362-1340)
Volume 23
Special Issue -- September 1988
ISBN 0-89791-289-6
ACM Order Number 548883
I don't know whether it's accurate, I haven't looked at it. I imagine
it is an exact copy of X3J13 document 88-002R, which is pretty close.
(3) I understand why you would like to have define-print-dispatch
merged with the CLOS stuff. I will look into that. However, I think there may be problems.
First, although not particularly shown in the examples, I have
found very elaborate type specifies for printing things (e.g.,
including satisfies clauses) to be quite useful. In the proposal
note the use of the specifier (CONS (AND SYMBOL (SATISFIES FBOUNDP))).
Also note the use of priorities to disambiguate between overlapping
type specifiers. This is very important to get propper
defaulting---i.e. specifying how to print lists in general as well
as particular special forms. Maybe some inheretence things can
make that work in CLOS, but it is not clear to me.
So what you're saying is that you want to use type specifiers that have
unclear subtype/supertype relationships, and compensate for that by
using numerical priorities. I understand now. CLOS cannot currently
handle that through the normal parameter specializer mechanism, because
it requires clear subtype/supertype relationships from the type
specifiers alone. On the other hand, one could make a form of method
combination that did the same thing as define-print-dispatch, but that
would be going through the back door. On the third hand, some of the
applicability testing could be moved into the body of the method and
call-next-method employed.
At this point I don't know what to say; expediency and elegance seem
to be in direct conflict. Maybe someone else has an idea. I certainly
will not block the thing for this point of esthetics, but it does raise
a red flag for me that something somewhere is inadequate.
Finally although it can certainly work, passing style of
printing arguments around does not appeal to me anywhere near as
much as multiple dispatch tables, because
when you write your first style, you have to set things up to
allow for more styles even if you never have more styles, or else
face a lot of work when you make a second style. It is also not
clear how this would all fit in with having a standard predefined
style that users can modify as they wish.
I think if you think about this harder you'll realize that dispatch tables
and style-of-printing arguments are isomorphic and differ only in some
minor internal implementation details.
It seems to me that the pretty printer and CLOS just do not have
the same idea of what an object is, and that while CLOS primarily
has a quasi-static association of methods to objects, the pretty
printer wants to support rapid wholesale change. Given these
differences, unification may not work as well as one might hope.
I think this is a non-issue, but the real problem is what you said above
complex type specifiers.
(4) Your suggestions for improving the functional interface basically
sound good to me, however I differ slightly with a couple of them.
Combining the :stream and :var sounds like a good idea.
However, The :arg argument is not mandatory. It is not used in the
second example I sent around with the functional interface proposal.
I don't recall seeing any examples of the functional interface. Let me
ask, how frequently is the :arg argument omitted? If it's omitted very
infrequently, it would be better to supply an explicit nil in those cases
than to say :arg in all the rest of the cases.
I think that making :prefix, :per-line-prefix, and :suffix functions
is overkill. One can always use #. after all.
No, the issue is a function that decides at run time what to output, rather
than having a canned string. Whether the string appears in the source or
is generated at compile time is of no moment. But if you don't want to
put in the extra flexibility, I won't complain, I don't have a specific
use for it in mind, I only proposed it on general principles.
∂20-Mar-89 2059 CL-Cleanup-mailer Issue: PATHNAME-COMPONENT-VALUE (version 1)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 20 Mar 89 20:59:17 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 561655; Mon 20-Mar-89 23:36:27 EST
Date: Mon, 20 Mar 89 23:36 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: PATHNAME-COMPONENT-VALUE (version 1)
To: CL-Cleanup@SAIL.STANFORD.EDU
cc: chapman%aitg.DEC@decwrl.dec.com
In-Reply-To: <19890320180405.2.MOON@EUPHRATES.SCRC.Symbolics.COM>
Message-ID: <19890321043621.8.MOON@EUPHRATES.SCRC.Symbolics.COM>
When constructing a pathname from components, conforming programs
must follow these rules:
16. Any component can be taken from the corresponding component
of another pathname on the same host and device.
A possible alternative that's worth considering is:
16. Any component can be taken from the corresponding component
of another pathname. When the two pathnames are for incompatible
file systems (in implementations that support multiple file
systems), an appropriate translation occurs. If no meaningful
translation is possible, an error is signalled. The definition
of "appropriate" and "meaningful" is implementation-dependent.
This provides more useful behavior that conforming programs can
depend upon, but the behavior cannot be as precisely specified.
A significant amount of the Symbolics Genera pathname facility is
related to this capability, and it's used a lot in heterogeneous
networks, so maybe this is a useful capability that ought to be
called for in the language. The cost to implementors is small since
they could define "appropriate" and "meaningful" to be whatever is
easiest for them, if their users don't complain.
∂21-Mar-89 0845 CL-Cleanup-mailer Issue: GENSYM-NAME-STICKINESS (Version 3)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 21 Mar 89 08:45:45 PST
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 561958; Tue 21-Mar-89 11:45:31 EST
Date: Tue, 21 Mar 89 11:45 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: GENSYM-NAME-STICKINESS (Version 3)
To: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <890321114510.2.KMP@BOBOLINK.SCRC.Symbolics.COM>
Hopefully this is a final version, ready for vote.
Guy has already reviewed it and approves of the changes
(removing GENSYM-COUNTER, adding variable *GENSYM-COUNTER*).
-kmp
-----
Issue: GENSYM-NAME-STICKINESS
Forum: Cleanup
References: GENSYM (p169)
Category: CHANGE
Edit history: 14-Feb-89, Version 1 by Pitman
15-Mar-89, Version 2 by Steele (add GENSYM-COUNTER function)
20-Mar-89, Version 3 by Pitman (make it a variable)
Problem Description:
Many people avoid use of the argument to GENSYM because the argument
is `sticky' and such stickiness can lead to confusion. The problem is
that if any application (usually a macro) uses the gensym argument at
all, then all applications are forced to. If they do not, they risk
finding that the `helpful' argument supplied in some previous call will
be harmful to them.
Proposal (GENSYM-NAME-STICKINESS:LIKE-TEFLON)
Define that if an optional argument [either a string or a number] is
given to GENSYM, it does NOT have a side-effect on GENSYM's internal state.
Introduce a new variable, *GENSYM-COUNTER*, which holds the state of
the gensym counter. That is, the next symbol generated by GENSYM will
be number n. The initial value of this variable is not defined, but
must always be a non-negative integer. This variable may be either
assigned or bound by users at any time, but always to a non-negative
integer.
Deprecate the use of a numeric argument to GENSYM.
Rationale:
Conscientious programmers are forced now to write their own GENSYM
lookalikes because they know the system's GENSYM has an invasive
effect. This defeats the primary intended function of GENSYM, which
is to satisfy the most common idiomatic use of MAKE-SYMBOL.
The stickiness of the GENSYM prefix was an attempt to be gratuitously
compatible with Maclisp, at the expense of good programming pratice.
Users who need the old behavior of GENSYM can trivially implement
that behavior using MAKE-SYMBOL.
Occasionally you want to reset the GENSYM counter so that, for example,
you can get the compiler to generate the same symbol names again
(good for comparing results to see what really changed).
Test Case:
;; #1: Test stickiness of name part.
(CHAR-EQUAL (CHAR (SYMBOL-NAME (SECOND (LIST (GENSYM "A") (GENSYM)))) 0)
#\G)
=> NIL ;under CLtL
=> T ;under this proposal
;; #2: Test stickiness of number part.
(= (PARSE-INTEGER (PROGN (GENSYM 6789) (STRING (GENSYM "G"))) :START 1)
6790)
=> T ;under CLtL
=> NIL ;under this proposal (except when *gensym-counter* happens to align)
;; #3: Illustrate use of new variable.
(STRING= (SYMBOL-NAME (LET ((*GENSYM-COUNTER* 43)) (GENSYM "FOO")))
"FOO43")
=> T ;under this proposal (not meaningful previously)
Current Practice:
Symbolics Cloe and Genera are compatible with CLtL, so this would be an
incompatible change.
Cost to Implementors:
Very small.
If any implementations currently use a more compact representation for
the internal state of GENSYM than a variable holding a string and a
separate variable holding an integer, they might be forced to change.
Even then, the change would proabably still be quite small.
Cost to Users:
Most uses of GENSYM do not depend on the stickiness of the name, so the
change would be compatible. In some cases, the change would be an
improvement. Even in the worst case where someone depends on stickiness,
it's extremely straightforward to write the couple of lines of code to
produce an application based on MAKE-SYMBOL that is at least as flexible
as GENSYM, and often moreso.
Cost of Non-Adoption:
Good programmers would avoid using the argument to GENSYM (or using
GENSYM altogether) in many situations where they ought not have to.
Benefits:
Gensyms which appear to convey information through their name would not
accidentally pop out and cause confusion in places where they oughtn't.
Making the gensym counter visible as a variable means that people will
be able to bind the gensym counter locally when they don't want to affect
the global counter.
Aesthetics:
Unnecessary global state changes are hard to reason about. This would
be a small simplification.
Discussion:
Pitman claims to have written a non-sticky GENSYM function for nearly
every one of the dozen or so large systems that he's written or worked
on in the last decade in order to get around the stated problem.
Others have suggested similar experience.
Pitman and Steele support LIKE-TEFLON.
∂21-Mar-89 1503 CL-Cleanup-mailer New cleanup issues
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 21 Mar 89 15:02:53 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 562318; Tue 21-Mar-89 18:01:47 EST
Date: Tue, 21 Mar 89 18:01 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: New cleanup issues
To: Masinter.pa@XEROX.COM
cc: CL-Cleanup@SAIL.STANFORD.EDU
Message-ID: <19890321230141.4.MOON@EUPHRATES.SCRC.Symbolics.COM>
Line-fold: No
Since you were on travel, I took the liberty of mailing a few
additional issues to X3J13. I'll bring at least one copy of
these to the meeting, and I hope if there is time we can discuss
them and vote to get them out of the way. None should be controversial.
∂21-Mar-89 1601 CL-Cleanup-mailer New issue: WITH-OPEN-FILE-DOES-NOT-EXIST
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 21 Mar 89 16:01:17 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 562394; Tue 21-Mar-89 18:59:52 EST
Date: Tue, 21 Mar 89 18:59 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: New issue: WITH-OPEN-FILE-DOES-NOT-EXIST
To: peck@Sun.COM
cc: cl-cleanup@SAIL.STANFORD.EDU
In-Reply-To: <8903180525.AA21223@denali.sun.com>
Message-ID: <19890321235935.6.MOON@EUPHRATES.SCRC.Symbolics.COM>
I think WITH-OPEN-FILE-DOES-NOT-EXIST:STREAM-IS-NIL is clearly correct,
although I agree that CLtL doesn't really say.
∂21-Mar-89 1643 CL-Cleanup-mailer Issue: PATHNAME-COMPONENT-VALUE (version 1)
Received: from Think.COM by SAIL.Stanford.EDU with TCP; 21 Mar 89 16:43:10 PST
Return-Path: <barmar@Think.COM>
Received: from OCCAM.THINK.COM by Think.COM; Tue, 21 Mar 89 19:20:00 EST
Date: Tue, 21 Mar 89 19:21 EST
From: Barry Margolin <barmar@Think.COM>
Subject: Issue: PATHNAME-COMPONENT-VALUE (version 1)
To: David A. Moon <Moon@stony-brook.scrc.symbolics.com>
Cc: cl-cleanup@sail.stanford.edu
In-Reply-To: <19890321225242.9.MOON@EUPHRATES.SCRC.Symbolics.COM>
Message-Id: <19890322002110.7.BARMAR@OCCAM.THINK.COM>
This is all well and good, but it doesn't address the BIGGEST obstacle
to portable use of MAKE-PATHNAME: uppercase vs lowercase. If I can't
write something as simple as
(setq dp (pathname "/u/barmar/foo.lisp"))
(namestring (make-pathname :name "bar" :defaults dp))
and have it mean the same thing in Lucid and Genera, what good is all
the rest? Anyone trying to deal with pathnames portably needs to write
a set of wrapper functions, as Thinking Machines has. Your proposals
don't really make this much easier.
The only effect of the various pathname proposals is to extend the
standard so that Symbolics's implementation conforms. I have no problem
with this goal, but I think the approach is wrong. What's the point of
rules 1-8, which specify the data types that the pathname accessors may
return, but don't specify the semantics of the values? If we're not
going to specify all the semantics, we might as well just say that they
can return any type, since there's nothing that a portable program can
do besides stick the values in another pathname. I think the only
useful rules in the whole list are 11 (any component can be NIL), 12
(any component can be :WILD), 15 (the version can be :NEWEST), and 16
(any component may be copied to the corresponding component of another
pathname on the same (EQL? EQUAL?) host and device). Rule 13 (most
components can be strings) is not useful because it doesn't define the
relationship between the string specified and the name of the file that
will be accessed (CLtL doesn't say whether (make-pathname :name "FOO")
accesses a file named "FOO", "foo", or "BAR").
Background:
For those of you not familiar with Genera's mechanism for dealing with
pathname case (with which I can't really find fault, because it is the
only way to solve problem of name translation across OS types, but it
does result in portability problems), the above sequence results in
"/u/barmar/BAR.lisp" in Genera, but "/u/barmar/bar.lisp" in most Unix
implementations. In Genera, the string arguments to MAKE-PATHNAME, and
the results of the PATHNAME-<component> functions, are not necessarily
in the same case the actual pathname, but in a format called
"interchange case". In interchange format, uppercase represents the
preferred case for the OS, lowercase represents the opposite case, and
mixed case is used verbatim. This allows you to do
(make-pathname :name (pathname-name <unix-path>) :defaults <vms-path>)
and have the lowercase Unix name translated to an uppercase VMS name
automatically.
Unfortunately, I can't think of any way to solve this problem in the
standard without incorporating the whole concept of interchange case
into it. There might not be too much opposition to it if we change the
design so that lowercase were used to represent the preferred case,
though. How many uppercase-preferred systems are used much for Common
Lisp? Are there any besides VAX/VMS? (Uppercase-only systems such as
MS-DOS and case-insensitive systems such as Macintosh don't count, since
they can use uppercase or lowercase interchangeably without affecting
the semantics.)
By the way, there should probably be a rule somewhere that says that
portable programs shouldn't expect to be able to create and/or access
distinct files whose pathname components differ only in case.
∂21-Mar-89 1752 CL-Cleanup-mailer Issue: PATHNAME-COMPONENT-VALUE (version 1)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 21 Mar 89 17:52:34 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 562499; Tue 21-Mar-89 20:49:08 EST
Date: Tue, 21 Mar 89 20:48 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: PATHNAME-COMPONENT-VALUE (version 1)
To: Barry Margolin <barmar@Think.COM>
cc: cl-cleanup@SAIL.STANFORD.EDU
In-Reply-To: <19890322002110.7.BARMAR@OCCAM.THINK.COM>
Message-ID: <19890322014857.1.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Tue, 21 Mar 89 19:21 EST
From: Barry Margolin <barmar@Think.COM>
This is all well and good, but it doesn't address the BIGGEST obstacle
to portable use of MAKE-PATHNAME: uppercase vs lowercase.
PATHNAME-COMPONENT-CASE addresses that; it's a separate issue. I don't
know whether it's on the agenda for next week, but I hope it is.
The only effect of the various pathname proposals is to extend the
standard so that Symbolics's implementation conforms.
Well, I certainly hope that with all the pathname proposals together,
that is not the only effect! The goal is to constrain the semantics
of pathnames enough to allow writing portable pathname-using programs,
so people will stop complaining that pathnames are a useless wart.
Maybe it was wrong to break it up into separate issues.
I have no problem
with this goal, but I think the approach is wrong. What's the point of
rules 1-8, which specify the data types that the pathname accessors may
return, but don't specify the semantics of the values? If we're not
going to specify all the semantics, we might as well just say that they
can return any type, since there's nothing that a portable program can
do besides stick the values in another pathname. I think the only
useful rules in the whole list are 11 (any component can be NIL), 12
(any component can be :WILD), 15 (the version can be :NEWEST), and 16
(any component may be copied to the corresponding component of another
pathname on the same (EQL? EQUAL?) host and device). Rule 13 (most
components can be strings) is not useful because it doesn't define the
relationship between the string specified and the name of the file that
will be accessed (CLtL doesn't say whether (make-pathname :name "FOO")
accesses a file named "FOO", "foo", or "BAR").
I think you're partly right here. It was probably a mistake to try to
constrain the types of "structured" values, because there is nothing
that a portable program can do with a "structured" value that depends on
the type.
As for strings, the intent was that with PATHNAME-COMPONENT-CASE the
relation between the string and the name of the file is fully specified;
I guess that wasn't at all clear from the PATHNAME-COMPONENT-VALUE
writeup. Similarly, with PATHNAME-SUBDIRECTORY-LIST the relation
between the list and the name of the directory is fully specified.
I see the proposal for PATHNAME-COMPONENT-CASE is rather stale, I'll
see if I can work up a version updated from the discussion tonight or
tomorrow.
By the way, there should probably be a rule somewhere that says that
portable programs shouldn't expect to be able to create and/or access
distinct files whose pathname components differ only in case.
Good point.
∂21-Mar-89 2227 CL-Cleanup-mailer Issue: PATHNAME-COMPONENT-VALUE (version 1)
Received: from Think.COM by SAIL.Stanford.EDU with TCP; 21 Mar 89 22:27:46 PST
Return-Path: <barmar@Think.COM>
Received: from kulla.think.com by Think.COM; Wed, 22 Mar 89 00:54:22 EST
Received: by kulla.think.com; Wed, 22 Mar 89 00:54:37 EST
Date: Wed, 22 Mar 89 00:54:37 EST
From: barmar@Think.COM
Message-Id: <8903220554.AA25095@kulla.think.com>
To: Moon@stony-brook.scrc.symbolics.com
Cc: cl-cleanup@sail.stanford.edu
In-Reply-To: David A. Moon's message of Tue, 21 Mar 89 20:48 EST <19890322014857.1.MOON@EUPHRATES.SCRC.Symbolics.COM>
Subject: Issue: PATHNAME-COMPONENT-VALUE (version 1)
Not being on cl-cleanup, I wasn't aware of PATHNAME-COMPONENT-CASE.
You may be right that it was wrong to break up the issues. On the
other hand, merging them all together would probably result in a
2K-line issue, which is no fun, either.
barmar
∂22-Mar-89 1054 CL-Cleanup-mailer PRETTY-PRINT-INTERFACE, version 4
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 22 Mar 89 10:54:13 PST
Received: from wheat-chex.ai.mit.edu by life.ai.mit.edu; Wed, 22 Mar 89 13:54:36 EST
Received: from localhost by wheat-chex.ai.mit.edu; Wed, 22 Mar 89 13:54:34 EST
Date: Wed, 22 Mar 89 13:54:34 EST
From: dick@wheaties.ai.mit.edu
Message-Id: <8903221854.AA10669@wheat-chex.ai.mit.edu>
To: cl-cleanup@sail.stanford.edu
Subject: PRETTY-PRINT-INTERFACE, version 4
Version 3 (by Guy Steele Jr) supersedes version 2 and is changed from
version 1 as follows: adds a functional interface to supplement the
interface through FORMAT, and reflects comments by Barrett and
Pierson.
Version 4 (by Dick Waters) is changed from version 3 as follows: The
short summary is updated to reflect the functional interface. The
functional interface is changed following suggestions made by Dave Moon.
The proposal is amended in a few minor ways to increase the
compatibility with variable width fonts. Additional discussion has been
added with regard to the advantages of XP with regard to handling
circularity detection and abbreviation, the interaction with CLOS, and
the extended type specifier CONS used by XP.
The document attached to version 1 has also been fully revised, but is
sent in a separate message due to mailer problems.
--Dick
Issue: PRETTY-PRINT-INTERFACE
References: Description of XP by Dick Waters (attached)
*PRINT-PRETTY* (CLtL p. 371)
WRITE (CLtL p. 382)
PPRINT (CLtL p. 383)
FORMAT (CLtL pp. 385-407)
FORMAT ~T directive (CLtL pp. 398-399)
FORMAT ~< directive (CLtL pp. 404-406)
Related issues:
Category: CLARIFICATION CHANGE ADDITION
Edit history: Version 1, 24-Feb-89 by Steele
Version 2, 15-Mar-89 by Steele and Waters
Version 3, 15-Mar-89 by Steele
Version 4, 22-Mar-89 by Waters
Problem description:
At present, Common Lisp provides no specification whatsoever of how
pretty-printing is to be accomplished, and no way for the user to control
it. In particular, there is no protocol by which a user can write a
print-function for a structure, or a method for PRINT-OBJECT, that will
interact smoothly with the built-in pretty-printer in a portable manner.
Proposal (PRETTY-PRINT-INTERFACE:XP):
Adopt the interfaces and protocols of the XP pretty-printer by Dick Waters,
described in full in the attached 12-page document. Here is a very brief
summary of the proposal.
New variables: *PRINT-DISPATCH*
*PRINT-RIGHT-MARGIN*
*DEFAULT-RIGHT-MARGIN*
*PRINT-MISER-WIDTH*
*PRINT-LINES*
*LAST-ABBREVIATED-PRINTING*
New functions: COPY-PRINT-DISPATCH
FILL-STYLE
LINEAR-STYLE
TABULAR-STYLE
CONDITIONAL-NEWLINE
LOGICAL-BLOCK-TAB
LOGICAL-BLOCK-INDENT
New macros: DEFINE-PRINT-DISPATCH
WITHIN-LOGICAL-BLOCK
LOGICAL-BLOCK-COUNT
LOGICAL-BLOCK-POP
New FORMAT directives: ~W ~_ ~I ~:T ~/name/ ~<...~:>
New # reader macro: #"..."
The function WRITE is extended to accept additional keyword arguments
:DISPATCH, :RIGHT-MARGIN, :LINES, and :MISER-WIDTH corresponding to the
first four of the new variables.
Examples: See attached document.
Rationale:
There ought to be a good user interface to the pretty printer.
This is the only proposal for which there is a portable implementation
that has seen extensive use and is being made freely available.
Current practice:
XP son of PP son of GPRINT son of PRINT* is the latest in a line of pretty
printers that goes back 13 years. All of these printers use essentially
the same basic algorithm and conceptual interface. Further, except for
PRINT*, which was implemented solely to satisfy the author's personal
needs, each of these printers has had extensive use. XP has been in
experimental use as the pretty printer in CMU Common Lisp for 6 months. PP
has been the pretty printer in DEC Common Lisp for the past 3 years. Prior
to three years ago, GPRINT was used for 2 years as the pretty printer in
DEC Common Lisp. In addition, GPRINT has been the pretty printer in
various generations of Symbolics Lisp for upwards of 5 years.
(See Waters R.C., "User Format Control in a Lisp Prettyprinter", ACM TOPLAS,
5(4):513--531, October 1983.)
Cost to Implementors:
A fair amount of effort (perhaps a few man-weeks at most).
Source code for XP is available to all comers from Dick Waters, and
the system is documented in great detail:
Waters, Richard C., "XP: A Common Lisp Pretty Printing System",
Artificial Intelligence Laboratory Technical Memo 1102,
Massachusetts Institute of Technology, Cambridge MA, March 1989.
Cost to Users: None (I think). This is an upward-compatible extension.
Cost of non-adoption: Continued inability for user print-functions
to interact with the pretty-printer in a useful and portable manner.
Performance impact: XP is claimed to be quite fast.
Benefits: User control of pretty-printing in a portable manner.
Aesthetics:
Using ~<...~:> may strike some as uncomfortably close in the syntactic
space of FORMAT directives to the existing ~<...~>. However, it is very
unlikely that both of these directives (pretty-print logical block and
columnar justification, respectively) will be used in the same call to
FORMAT. Previous versions of XP used ~!...~. instead of ~<...~:> but this
made FORMAT strings very difficult to read; it is preferable to have
a directive that looks like matching brackets of some sort.
Dan Pierson comments: You might mention that some people will undoubtedly
find piling more hair on FORMAT ugly (of course these same people may
well find FORMAT in general ugly :-)).
Discussion:
Zetalisp used ~:T to mean pixelwise tabulation, so the use of ~:T
suggested here may be a problem. If so, another suggestion for naming
this directive would be appropriate.
The ~/.../ directive is already in Zetalisp, and is not an idea new
to this proposal. However, it should be noted that the proposal for
~/.../ here is simpler than, and incompatible with, the current Zatalisp
practice.
Guy Steele and Dick Waters strongly support this proposal. (As an example,
Guy Steele has a portable simulator for Connection Machine Lisp, and would
like very much to have xappings and xectors pretty-print properly.)
Dan Pierson comments: You can add me to the list of strong supporters of
this proposal. While the proposal is long and complex, it is supported by
a long history of usage in several different Lisp environments. Unlike
some earlier members of this family, this version fits cleanly enough into
the rest of Common Lisp to warrant standardization.
The utility of *PRINT-LINES* becomes more obvious if it is pointed out
that Dick's pretty printers are implemented to print each line as it
is computed. This means that a small value for *PRINT-LINES* saves
significant time as well as output medium space. In fact, many people
find that a very pleasant REP loop is created by setting *PRINT-LINES*
to a value from 1-4, *PRINT-PRETTY* to T, and defining a short-name
function (say (PP*)) that funcalls *LAST-ABBREVIATED-PRINTING* with
abbreviation bound off. This is almost as fast and compact as, and
MUCH more readable than, a non-pretty-printing REP loop.
The advantages of compiled format strings (format functions) should be
brought out as benefits in their own right. The current proposal just
mentions them as a minor feature of XP.
At first this struck me a very cute end run around the failure of
STREAM-INFO, then I realized that one of the problems with STREAM-INFO
may have been that it was a standard at the wrong level. STREAM-INFO
permitted people to use XP, but not to count on it. This proposal
makes it possible to write portable code whose new data structures and
language elements print correctly in whatever Common Lisp environment
they're run in. [End of comments by Pierson]
It has been noted by Guy Steele that some places in the initial document
where it says that circularity detection is handled correctly, this is
true a fortiori following the decision on PRINT-CIRCLE-STRUCTURE.
However, Waters notes that the vote on PRINT-CIRCLE-STRUCTURE said
nothing about the handling of *PRINT-LEVEL*. Therefore, the fact that
XP handles *PRINT-LEVEL* correctly is an improvement.
In addition, PRINT-CIRCLE-STRUCTURE is also silent on what is supposed
to happen if a user program decomposes a list itself (e.g., with DOLIST
or ~{~}) rather than calling a print function. Assumedly *PRINT-CIRCLE*
etc. is not handled in this case. In contrast, if one uses
WITHIN-LOGICAL-BLOCK or ~<~:>, then *PRINT-CIRCLE*, *PRINT-LEVEL*, and
*PRINT-LENGTH* are all automatically handled correctly.
For example, (format nil "-~1{~A ~A ~A ~A ~A ~}-" '#1=(1 #1# 2 . #1#))?
produces "-1 #1=(1 #1# 2 . #1#) 2 1 #1=(1 #1# 2 . #1#) -"
even under PRINT-CIRCLE-STRUCTURE and
(format nil "-~1{~A ~}-" '#1=(1 #1# 2 . #1#))
cause infinite looping. However, in XP,
(format nil "-~:<~W ~W ~W ~W ~W~:>-" '#1=(1 #1# 2 . #1#))
produces "-#1=(1 #1# 2 . #1#)-".
This proves to be very useful when writing pretty printing functions for things.
Note also that ~<~:> supports *print-level* and *print-length* correctly.
All the same things can be said about the functional interface and using
WITHIN-LOGICAL-BLOCK rather than traversing a list yourself in some fashion.
All in all, Waters claims that PRINT-CIRCLE-STRUCTURE covers at most 1/4
of what XP does in support of *print-circle* and does not cover anything
of what XP does to support *print-level*, *print-length*, and
robustness in the face of malformed arguments. These are vital
features for writing printing functions that really work right all the time.
It has been noted by Dave Moon that things would be much more elegant if
DEFINE-PRINT-DISPATCH could be expressed directly as a CLOS DEFMETHOD
for an appropriate generic function. Dick Waters agrees with this.
However, DEFINE-PRINT-DISPATCH depends on type specifiers that are more
complex than the ones CLOS deals with and ones that do not have clear
subtype/supertype relationships, compensating for the latter problem by
supporting numerical priorities to disambiguate things. (The defaulting
behavior is a key feature of the pretty printer.) At the very least,
this means that DEFINE-PRINT-DISPATCH will not fit into CLOS in a simple way.
Given the problems, Moon suggests that "it does seem that right now it
might be best to keep a separate DEFINE-PRINT-DISPATCH macro, with the
idea that the expansion is implementation-dependent at the moment, but
might some day be changed to be defined to expand into DEFMETHOD. I
haven't looked to see whether any syntactic changes would be appropriate
to make that transition smoother."
(Waters also worries that the overhead needed to locate the right CLOS
method would seriously degrade the pretty printer, because the printer
has to do this for every part of every object printed. This dispatching is
currently done by very fast code that is tuned to take advantage of the
observed distribution of kinds of objects that have special pretty
printers attached to them. Even with this special purpose code,
dispatching takes a significant part of the pretty printer's time.)
Dave Moon also comments that it is not good to have something that looks
like a type specifier (i.e., the extended form of the CONS type specifier
used by DEFINE-PRINT-DISPATCH) and yet is not a real type specifier. He
suggests that we should either amend Common Lisp to accept the extended
form of the CONS type specifier, or stop having DEFINE-PRINT-DISPATCH
use it.
Waters supports any course of action that retains the use of the
extended CONS type specifier in conjunction with DEFINE-PRINT-DISPATCH.
However, he notes that the trade-off is clear. One could avoid the
complex CONS type specifier without any significant loss of
functionality by introducing a new macro DEFINE-LIST-PRINT-DISPATCH that
is identical to DEFINE-PRINT-DISPATCH except that it is relevant only to
conses and the type specifier applies to the CAR of the object to be
printed rather than to the object as a whole. However, this appears to
him to be significantly less elegant than the current approach.
-------------------- detailed documentation --------------------
The full description is too large to fit in with everything else in this
message. A fully correct version follows in a separate message. The
stuff below summarizes all of the changes from the full description in
version 1.
Amendments
To a considerable extent, the design of the XP interface is completely
neutral about the issue of variable- versus fixed- width fonts. In
particular, most of the discussion of how the formating proceeds either
talks about absolute positions of zero or talks about something being
in the same horizontal position as something else. These statements are
all font-independent. (Further, although Waters' current implementation
does not support variable-width fonts, the algorithms used could be
extended to support them without radical changes.)
Nevertheless, there are 9 places where users specify explicit
non-zero lengths: the variables *PRINT-RIGHT-MARGIN*,
*DEFAULT-RIGHT-MARGIN*, and *PRINT-MISER-WIDTH*, the numeric
arguments to ~T, ~I, and ~/tabular-style/ and their associated functions
LOGICAL-BLOCK-TAB, LOGICAL-BLOCK-INDENT, and TABULAR-STYLE.
It is proposed that all of these lengths be in the same units, and that
this unit be ems (the length of an "m" in the font currently being used
to output characters to the relevant output stream at the moment that
the command is encountered or a variable is consulted).
It is further proposed that users and implementors be advised to set
things up so that explicit lengths do not have to be specified. For
implementors, this means making streams smart enough that they know how
wide they are. (This avoids the use of *PRINT-RIGHT-MARGIN* and
*DEFAULT-RIGHT-MARGIN* in most situations.) For users, this means
relying on streams knowing their own widths (which is a good idea for
adaptability in any case) and using ~:I to specify indentations wherever
possible. Further, it should be noted that since *PRINT-MISER-WIDTH* is
essentially heuristic in nature, it does not matter if its value is only
an approximate length and users will only need to change the
value of *PRINT-MISER-WIDTH* in unusual situations. This leaves only
tabbing as an area where explicit lengths have to be specified on a
regular basis. Fortunately, approximate lengths are often acceptable in
this situation as well.
Functional Interface
The primary interface to operations for dynamically determining the
arrangement of output is provided through FORMAT. This is done,
because FORMAT strings are typically the most convenient way of
interacting with pretty printing. However, these operations have
nothing inherently to do with FORMAT per se. In particular, they can
also be accessed via the six functions and macros below.
WITHIN-LOGICAL-BLOCK (STREAM-SYMBOL LIST [Macro]
:PREFIX :PER-LINE-PREFIX :SUFFIX)
&BODY BODY
In the manner of ~<...~:>, this macro causes printing to be
grouped into a logical block. The value NIL is always returned.
STREAM-SYMBOL must be a symbol. If it is NIL, it is treated the same as
if it were *STANDARD-OUTPUT*. If it is T, it is treated the same as if
it were *TERMINAL-IO*. The run-time value of STREAM-SYMBOL must be a
stream. The logical block is printed into this destination stream.
The BODY can contain any arbitrary Lisp forms. Within the BODY,
STREAM-SYMBOL is bound to a special kind of stream that supports dynamic
decisions about the arrangement of output and then forwards the output
to the destination stream. All the standard printing functions (e.g.,
WRITE, PRINC, TERPRI) can be used to print output into STREAM-SYMBOL.
All and only the output sent to STREAM-SYMBOL is treated as being in the
logical block. (It is an error to send any output directly to the
underlying destination stream.)
The :SUFFIX, :PREFIX, and :PER-LINE-PREFIX must all be expressions that
(at run time) evaluate to strings. :SUFFIX (which defaults to the null
string) specifies a suffix that is printed just after the logical block.
:PREFIX specifies a prefix to be printed before the beginning of the
logical block. :PER-LINE-PREFIX specifies a prefix that is printed
before the block and at the beginning of each new line in the block. It
is an error for :PREFIX and :PRE-LINE-PREFIX to both be used. If neither
is used, a :PREFIX of the null string is assumed.
LIST is interpreted as being a list that BODY is responsible for
printing. If LIST does not (at run time) evaluate to a list, it is
printed using WRITE. If *PRINT-CIRCLE* is not NIL and LIST is a
circular reference to a cons, then an appropriate #n# marker is printed.
If *PRINT-LEVEL* is not NIL and the logical block is at a dynamic
nesting depth of greater than *PRINT-LEVEL* in logical blocks, # is
printed. If either of the three conditions above occures, the indicated
special output is printed on STREAM-SYMBOL and the BODY is skipped along
with the printing of the prefix and suffix. (If the BODY is
not responsible for printing a list, then the first two tests above can
be turned off by supplying NIL for the LIST argument.)
CONDITIONAL-NEWLINE KIND &OPTIONAL (STREAM *STANDARD-OUTPUT*) [Function]
CONDITIONAL-NEWLINE is the functional equivalent of ~_. STREAM (which
defaults to *STANDARD-OUTPUT*) follows the standard conventions for
stream arguments to printing functions (i.e., NIL stands for
*STANDARD-OUTPUT* and T stands for *TERMINAL-IO*). The KIND argument
specifies the style of conditional newline. It must be one of :LINEAR,
:FILL, :MISER, or :MANDATORY. If STREAM is a special stream bound by
WITHIN-LOGICAL-BLOCK, a conditional newline is sent to it. Otherwise,
CONDITIONAL-NEWLINE has no effect. The value NIL is always returned.
LOGICAL-BLOCK-INDENT RELATIVE-TO N &OPTIONAL (STREAM *STANDARD-OUTPUT*) [Function]
LOGICAL-BLOCK-INDENT is the functional equivalent of ~I. STREAM (which
defaults to *STANDARD-OUTPUT*) follows the standard conventions for
stream arguments to printing functions. N specifies the indentation in
ems. If RELATIVE-TO is :BLOCK, this indentation is relative to the
start of the enclosing block (as for ~I). If RELATIVE-TO is :CURRENT,
the indentation is relative to the current output position (as for ~:I).
It is an error for RELATIVE-TO to take on any other value. If STREAM is
a special stream bound by WITHIN-LOGICAL-BLOCK, LOGICAL-BLOCK-INDENT
sets the indentation in the innermost enclosing logical block.
Otherwise, LOGICAL-BLOCK-INDENT has no effect. The value NIL is always
returned.
LOGICAL-BLOCK-TAB KIND COLNUM COLINC &OPTIONAL (STREAM *STANDARD-OUTPUT*)
LOGICAL-BLOCK-TAB is the functional equivalent of ~T. STREAM (which
defaults to *STANDARD-OUTPUT*) follows the standard conventions for
stream arguments to printing functions. The arguments COLNUM and COLINC
correspond to the two numeric parameters to ~T and are in terms of ems.
The KIND argument specifies the style of tabbing. It must be one of
:LINE (tab using ~T), :BLOCK (tab using ~:T), :LINE-RELATIVE (tab using
~@T), or :BLOCK-RELATIVE (tab using ~:@T). If STREAM is a special
stream bound by WITHIN-LOGICAL-BLOCK, tabbing is performed. Otherwise,
LOGICAL-BLOCK-TAB has no effect. The value NIL is always returned.
LOGICAL-BLOCK-POP ARGS &OPTIONAL (STREAM *STANDARD-OUTPUT*) [Macro]
LOGICAL-BLOCK-COUNT &OPTIONAL (STREAM *STANDARD-OUTPUT*) [Macro]
LOGICAL-BLOCK-POP is identical to POP except that it supports
*PRINT-LENGTH* and *PRINT-CIRCLE*. It is an error to use
LOGICAL-BLOCK-POP anywhere other than syntactically nested within a
call on WITHIN-LOGICAL-BLOCK.
ARGS must be a symbol or expression acceptable to POP. STREAM (which
defaults to *STANDARD-OUTPUT*) follows the standard conventions for
stream arguments to printing functions. If STREAM is a special stream
bound by WITHIN-LOGICAL-BLOCK, then LOGICAL-BLOCK-POP performs the
special operations described below. Otherwise, LOGICAL-BLOCK-POP is
identical to POP.
Each time LOGICAL-BLOCK-POP is called, it performs three tests. if
ARGS is not a cons, ". " is printed followed by ARGS. If
*PRINT-LENGTH* is NIL and LOGICAL-BLOCK-POP has already been called
*PRINT-LENGTH* times within the immediately containing logical block,
"..." is printed. If *PRINT-CIRCLE* is not NIL, and ARGS is a circular
reference, then ". " is printed followed by an appropriate #n# marker.
If either of the three conditions above occurs, the special output is
printed on :STREAM and the execution of the immediately containing
WITHIN-LOGICAL-BLOCK is terminated except for the printing of the
suffix. Otherwise, LOGICAL-BLOCK-POP pops the top value off of ARGS
and returns this value.
LOGICAL-BLOCK-COUNT is identical to LOGICAL-BLOCK-POP except that it
does not take an ARGS argument, always returns NIL, and only performs
the second test discussed above. It is useful when the components of a
non-list are being printed.
Using the functions above, TABULAR-STYLE could be defined as follows.
(defun tabular-style (s list &optional (colon? T) atsign? (tabsize nil))
(declare (ignore atsign?))
(if (null tabsize) (setq tabsize 16))
(within-logical-block (s list :prefix (if colon? "(" "")
:suffix (if colon? ")" ""))
(when list
(loop (write (logical-block-pop list s) :stream s)
(if (null list) (return nil))
(write-char #\space s)
(logical-block-tab :block-relative 0 tabsize s)
(conditional-newline :fill s)))))
The function below prints a vector using #(...) notation.
(defun print-vector (v *standard-output*)
(within-logical-block (nil nil :prefix "#(" :suffix ")")
(let ((end (length v)) (i 0))
(when (plusp end)
(loop (logical-block-count)
(write (aref v i))
(if (= (incf i) end) (return nil))
(write-char #\space)
(conditional-newline :fill))))))
FILL-STYLE STREAM LIST &OPTIONAL (COLON? T) ATSIGN?
LINEAR-STYLE STREAM LIST &OPTIONAL (COLON? T) ATSIGN?
TABULAR-STYLE STREAM LIST &OPTIONAL (COLON? T) ATSIGN? (TABSIZE 16)
The directives ~/fill-style/, ~/linear-style/, and ~/tabular-style/ are
supported by the three functions above. These functions can also be
called directly by the user. Each function prints parentheses around
the output if an only if COLON? (default T) is not NIL. Each function
ignores its ATSIGN? argument and returns NIL. (These arguments are
optional to facilitate the direct use of the three functions.) Each
function handles abbreviation and circularity detection correctly, and
uses WRITE to print LIST when given a non-list argument.
The function LINEAR-STYLE prints a list either all on one line, or with
each element on a separate line. The function FILL-STYLE prints a list
with as many elements as possible on each line. The function
TABULAR-STYLE is the same as FILL-STYLE except that it prints the
elements so that they line up in columns. This function takes an
additional argument TABSIZE (default 16) that specifies the column
spacing in ems.
[End of attached document]
∂22-Mar-89 1057 CL-Cleanup-mailer PRETTY-PRINT-INTERFACE, version 4
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 22 Mar 89 10:56:27 PST
Received: from wheat-chex.ai.mit.edu by life.ai.mit.edu; Wed, 22 Mar 89 13:56:35 EST
Received: from localhost by wheat-chex.ai.mit.edu; Wed, 22 Mar 89 13:56:33 EST
Date: Wed, 22 Mar 89 13:56:33 EST
From: dick@wheaties.ai.mit.edu
Message-Id: <8903221856.AA10674@wheat-chex.ai.mit.edu>
To: cl-cleanup@sail.stanford.edu
Subject: PRETTY-PRINT-INTERFACE, version 4
Issue: PRETTY-PRINT-INTERFACE
Full description of XP accompanying version 4 of the proposal
--------------------
Pretty Printing
Richard C. Waters
Pretty printing has traditionally been a black box process, displaying
program code using a set of fixed layout rules. Its utility can be greatly
enhanced by opening it up to user control.
By providing direct access to the mechanisms within the pretty printer that
make dynamic decisions about layout, the FORMAT directives ~_, ~I, and
~<...~:> make it possible to specify pretty printing layout rules as a part
of any function that produces output. They also make it very easy for
circularity detection and abbreviation based on length and nesting depth to
be supported by the function. The construct DEFINE-PRINT-DISPATCH makes it
possible to associate a user-defined pretty printing function with any type
of object. Together, these facilities enable users to redefine the way
code is displayed and allow the full power of pretty printing to be applied
to complex combinations of data structures.
Pretty Printing Control Variables
*PRINT-DISPATCH* [variable]
When *PRINT-PRETTY* is not NIL, the print dispatch table in
*PRINT-DISPATCH* controls the way objects are printed. The initial value
of *PRINT-DISPATCH* causes traditional pretty printing of Lisp code.
*PRINT-RIGHT-MARGIN* [variable]
*DEFAULT-RIGHT-MARGIN* [variable]
The goal of dynamic layout decisions (when pretty printing or when directly
specified via ~_, ~I, and ~<...~:>) is to keep the output between a pair of
margins. The left margin is set at the column where the output begins. If
this cannot be determined, the left margin is set to zero.
When *PRINT-RIGHT-MARGIN* is not NIL, it specifies the right margin to use
when making layout decisions. When *PRINT-RIGHT-MARGIN* is NIL (the
initial value), the right margin is set at the maximum line length that can
be displayed by the output stream without wraparound or truncation. If
this cannot be determined, the right margin is set to
*DEFAULT-RIGHT-MARGIN*. The initial value of *DEFAULT-RIGHT-MARGIN* is
implementation-dependent.
To allow for the possibility of variable-width fonts, both of these
variables are interpreted in terms of ems---the length of an "m"
in the font being used to display characters on the relevant output
stream at the moment when the variables are consulted.
*PRINT-MISER-WIDTH* [variable]
If *PRINT-MISER-WIDTH* is not NIL, the pretty printer switches to a compact
style of output (called miser style) whenever the width available for
printing a substructure is less than or equal to *PRINT-MISER-WIDTH* ems. The
initial value of *PRINT-MISER-WIDTH* is implementation-dependent.
!
*PRINT-LINES* [variable]
When given a value other than its initial value of NIL, *PRINT-LINES*
limits the number of output lines produced when something is printed. If
an attempt is made to go beyond *PRINT-LINES* lines, " ---" is printed at
the end of the last line and printing stops.
(let ((*print-right-margin* 20) (*print-lines* 3))
(pprint '(setq a 1 b 2 c 3 d 4)))
(SETQ A 1
B 2
C 3 ---
*LAST-ABBREVIATED-PRINTING* [variable]
This variable records the last printing event where abbreviation occurred.
Funcalling its value (e.g., after turning off abbreviation) causes the
printing to happen a second time.
The function WRITE accepts keyword arguments :DISPATCH, :RIGHT-MARGIN,
:LINES, and :MISER-WIDTH corresponding to *PRINT-DISPATCH*,
*PRINT-RIGHT-MARGIN*, *PRINT-LINES*, and *PRINT-MISER-WIDTH*.
Compiling Format Control Strings
The control strings used by FORMAT are essentially programs that perform
printing. The readmacro character #"..." provides the efficiency of using
a compiled function for printing without losing the conciseness of FORMAT
control strings. In the notation #"...", the string following # is
identical to a FORMAT control string. However, the readmacro translates it
into an equivalent sharp-quoted function. The first expression below is
equivalent to the second.
#"~%~@{~S~↑, ~}"
#'(lambda (stream &rest args)
(terpri stream)
(loop (prin1 (pop args) stream)
(if (null args) (return nil))
(write-string ", " stream)))
In support of the above, FORMAT accepts functions as its second argument as
well as strings. When a function is provided, it is called with the
appropriate output stream as its first argument and the data arguments to
FORMAT as its remaining arguments. The function should perform whatever
output is necessary. The values returned by the function are ignored. The
directive ~? also accepts functions as well as control strings.
!
Dynamic Control of the Arrangement of Output
The following FORMAT directives support precise control of what should be
done when a piece of output is too large to fit in the space available.
Three concepts underlie the way these directives work---`logical blocks',
`conditional newlines', and `sections'.
The first line of Figure 1 shows a schematic piece of output. The
characters in the output are represented by "-". The positions of
conditional newlines are indicated by digits. The beginnings and ends of
logical blocks are indicated by "<" and ">" respectively.
The output as a whole is a logical block and the outermost section. This
section is indicated by the 0's on the second line of Figure 1. Logical
blocks nested within the output are specified by ~<...~:> directives.
Conditional newline positions are specified by ~_ directives. Each
conditional newline defines two sections (one before it and one after it)
and is associated with a third (the section immediately containing it).
The section after a conditional newline consists of: all the output up to,
but not including, (a) the next conditional newline immediately contained
in the same logical block; or if (a) is not applicable, (b) the next
newline that is at a lesser level of nesting in logical blocks; or if (b)
is not applicable, (c) the end of the output.
The section before a conditional newline consists of: all the output back
to, but not including, (a) the previous conditional newline that is
immediately contained in the same logical block; or if (a) is not
applicable, (b) the beginning of the immediately containing logical block.
The last four lines in Figure 1 indicate the sections before and after the
four conditional newlines.
The section immediately containing a conditional newline is the shortest
section that contains the conditional newline in question. In Figure 1,
the first conditional newline is immediately contained in the section
marked with 0's, the second and third conditional newlines are immediately
contained in the section before the fourth conditional newline, and the
fourth conditional newline is immediately contained in the section after
the first conditional newline.
<-1---<--<--2---3->--4-->->
000000000000000000000000000
11 111111111111111111111111
22 222
333 3333
44444444444444 44444
Figure 1: Example of logical blocks, conditional newlines, and sections.
Whenever possible, the pretty printer displays the entire contents of a
section on a single line. However, if the section is too long to fit in
the space available, line breaks are inserted at conditional newline
positions within the section.
!
~W [format directive]
WRITE -- An arg, any Lisp object, is printed obeying every printer control
variable (as by WRITE). In addition, ~W interacts correctly with depth
abbreviation, by not resetting the depth counter to zero. ~W does not
accept parameters. If given the colon modifier, ~W binds *PRINT-PRETTY* to
T. If given the atsign modifier, ~W binds *PRINT-LEVEL* and *PRINT-LENGTH*
to NIL.
~W provides automatic support for circularity detection. If *PRINT-CIRCLE*
is T and ~W is applied to an argument that has already been encountered
during the printing process, an appropriate #n# marker is inserted in the
output instead of printing the argument.
Circularity detection is supported by effectively doing the printing twice.
On the first pass, circularities are detected and the actual outputting of
characters is suppressed. On the second pass, the appropriate #n= and #n#
markers are inserted and characters are output.
~_ [format directive]
CONDITIONAL NEWLINE -- Without any modifiers, ~_ specifies a
`linear-style' conditional newline. A line break is inserted if and only
if the immediately containing section cannot be printed on one line. The
effect of this is that line breaks are either inserted at every
linear-style conditional newline in a logical block or at none of them.
~@_ specifies a `miser-style' conditional newline. A line break is
inserted if and only if the immediately containing section cannot be
printed on one line and miser style is in effect in the immediately
containing logical block. The effect of this is that miser-style
conditional newlines act like linear-style conditional newlines, but only
when miser style is in effect. Miser style is in effect for a logical
block if and only if the the starting column of the logical block is less
than or equal to *PRINT-MISER-WIDTH* columns from the right margin.
~:_ specifies a `fill-style' conditional newline. A line break is
inserted if and only if either (a) the following section cannot be printed
on the end of the current line, (b) the preceding section was not printed
on a single line, or (c) the immediately containing section cannot be
printed on one line and miser style is in effect in the immediately
containing logical block. If a logical block is broken up into a number
of subsections by fill-style conditional newlines, the basic effect is
that the logical block is printed with as many subsections as possible on
each line. However, if miser style is in effect, fill-style conditional
newlines act like linear-style conditional newlines.
~:@_ specifies a `mandatory-style' conditional newline. A line break is
always inserted. This implies that none of the containing sections can be
printed on a single line and will therefore trigger the insertion of line
breaks at linear-style conditional newlines in these sections.
When a line break is inserted by any type of conditional newline, any
blanks that immediately precede the conditional newline are omitted from
the output and indentation is introduced at the beginning of the next line.
By default, the indentation causes the following line to begin in the same
column as the first character in the immediately containing logical block.
The indentation can be changed via ~I.
There are a variety of ways unconditional newlines can be introduced into
the output (e.g., via ~% or by printing a string containing a newline
character). As with mandatory conditional newlines, this prevents any of
the containing sections from being printed on one line. In general, when
an unconditional newline is encountered, it is printed out without
suppression of the preceding blanks and without any indentation following
it. However, if a per-line prefix has been specified (see ~<...~:>), this
prefix will always be printed no matter how a newline originates.
!
~<...~:> [format directive]
LOGICAL BLOCK -- If ~:> is used to terminate a ~<...~>, the directive
delimits a logical block. In addition, ~<...~:> descends into the
corresponding FORMAT argument (a list) in the same way as the directive
~1{...~:}. ~↑ can be used to exit from ~<...~:> just as it can be used to
exit from ~{...~}.
The portion of a FORMAT control string enclosed in ~<...~:> can be divided
into segments ~<prefix~;body~;suffix~:> by ~; directives. It is an error
for the enclosed portion to be divided into more than three segments. If
the enclosed portion is divided into only two segments, the suffix defaults
to the null string. If the enclosed portion consists of only a single
segment, both the prefix and the suffix default to the null string. If the
colon modifier is used with ~<...~:>, the prefix and suffix default to "("
and ")" (respectively) instead of to the null string.
The prefix and suffix must both be constant strings. They cannot contain
FORMAT directives. The body can be any arbitrary FORMAT control string.
The prefix is printed out just before the logical block is started and the
suffix is printed out just after the logical block ends. This is done even
when the argument corresponding to ~<...~:> is an empty list.
If ~<...~:> is applied to an argument that is not a list, the directive is
ignored (suppressing the output of the prefix and suffix) and the offending
argument is printed using ~W. This makes it easier to write FORMAT strings
that are robust in the face of malformed arguments.
During the processing of the FORMAT string nested in ~<...~:>, arguments
are taken one by one from the list passed to ~<...~:>. If an attempt is
made to access an argument at a time when the remaining portion of this
argument list is not a cons, then ". " is inserted in the output, ~W is
used to print out the remaining argument list, and the processing of the
logical block is terminated, except for printing the suffix (if any). This
makes it easier to write FORMAT strings that are robust in the face of
malformed argument lists. (Note that ~↑ exits only when the remaining
argument list is NIL.)
~<...~:> provides automatic support for depth abbreviation. If
*PRINT-LEVEL* is not NIL and ~<...~:> is encountered at a dynamic nesting
depth in logical blocks greater than *PRINT-LEVEL*, "#" is inserted in the
output and the ~<...~:> and its associated argument are ignored.
~<...~:> provides automatic support for length abbreviation. If
*PRINT-LENGTH* is not NIL, a count is kept of the number of arguments used
within the ~<...~:>. If this count ever reaches *PRINT-LENGTH*, " ..." is
inserted in the output and the processing of the logical block is
terminated, except for printing the suffix (if any).
~<...~:> also provides automatic support for circularity detection. If
*PRINT-CIRCLE* is T and ~<...~:> (without the atsign modifier) is applied
to a list argument that has already been encountered during the printing
process, an appropriate #n# marker is inserted in the output and the
~<...~:> and its associated argument are ignored.
!
In addition, if an attempt is made to access an argument from the list
passed to ~<...~:>, at a time when the remaining portion of this list has
already been encountered during the printing process, ". #n#" is inserted
in the output and the processing of the logical block is terminated, except
for printing the suffix (if any). This catches instances of CDR
circularity in lists.
For circularity detection to work correctly when printing an object, every
part of the object that is a cons must be printed using ~<...~:> and every
non-cons must be printed using ~W. If some part is printed some other way
(e.g., using ~S), circularities involving this part will be missed.
If the atsign modifier is used with ~<...~:>, the entire remaining argument
list is passed to the directive as its argument. Unlike ~1@{...~} all of
the remaining arguments are always consumed by ~@<...~:>, even if they are
not all used by the FORMAT string nested in the directive.
As an example of the interaction of conditional newlines and logical
blocks, consider the following. The FORMAT string specifies how to pretty
print a LET. The outermost ~:<...~:> decomposes the input and specifies
that parentheses should be printed in the output. The
~:<~@{~:<~@{~W~↑~ _~}~:>~↑ ~:_~}~:> decomposes the list of binding pairs.
Each pair in the list is itself decomposed and printed using
~:<~@{~W~↑ ~_~}~:>. (An iteration is used in this FORMAT string instead of
merely decomposing the pair into two elements so that a malformed pair
containing more than two elements will print readably.) A space and a
fill-style conditional newline are placed after each pair except the last.
The ~@{~↑~_ ~W~} prints out the forms in the body of the LET separated by
spaces and linear-style conditional newlines.
(format T #"~:<~W~↑ ~:<~@{~:<~@{~W~↑ ~_~}~:>~↑ ~:_~}~:>~
~@{~↑~_ ~W~}~:>"
'#1=(let (x (*print-length* (f (g 3)))
(z . 2) (k (car y)))
(setq x (sqrt z)) #1#))
Suppose that *PRINT-PRETTY* is T, *PRINT-LEVEL* is 4, and *PRINT-CIRCLE* is
T. If the line length is greater than or equal to 77, the output produced
by the FORMAT above appears on one line. However, if the line length is
76, line breaks are inserted at the linear-style conditional newlines
separating the forms in the body and the output below is produced. Note
that, the degenerate binding pair X is printed readably even though it
fails to be a list; a depth abbreviation marker is printed in place of
(G 3); the binding pair (Z . 2) is printed readably even though it fails
to be a proper list; and appropriate circularity markers are printed.
#1=(LET (X (*PRINT-LENGTH* (F #)) (Z . 2) (K (CAR Y)))
(SETQ X (SQRT Z))
#1#)
If the line length is reduced to 35, a line break is inserted at one of the
fill-style conditional newlines separating the binding pairs.
#1=(LET (X (*PRINT-PRETTY* (F #))
(Z . 2) (K (CAR Y)))
(SETQ X (SQRT Z))
#1#)
!
Suppose that the line length is further reduced to 22 and *PRINT-LENGTH* is
set to 3. In this situation, line breaks are inserted after both the first
and second binding pairs. In addition, the second binding pair is itself
broken across two lines. Clause (b) of the description of fill-style
conditional newlines prevents the binding pair (Z . 2) from being printed
at the end of the third line. Note that the length abbreviation hides the
circularity from view and therefore the printing of circularity markers
disappears as well.
(LET (X
(*PRINT-LENGTH*
(F #))
(Z . 2) ...)
(SETQ X (SQRT Z))
...)
If ~@; is used to terminate the prefix in ~<...~:>, the prefix is a
`per-line' prefix. A per-line prefix is printed at the beginning of every
line in the logical block, rather than just before the start of the block
as a whole. Each instance of the prefix is lined up below the occurrence
of the prefix on the first line. With a line length of 25, the form below
produces the output shown.
(format T #"~<;;; ~@;Roads ~<= ~@;~W, ~:_~W~:> ~:_ Town ~W~:>"
'((elm cottonwood) boston))
;;; Roads = ELM,
;;; = COTTONWOOD
;;; Town BOSTON
If ~<...~:> is terminated with ~:@>, then a fill-style conditional newline
is automatically inserted after each group of blanks immediately contained
in the body (except for blanks after a ~<newline> directive). This makes
it easy to achieve the equivalent of paragraph filling. With a line length
of 12, the form below produces the output shown.
(format T #"~<~:(~W~) street goes to ~:(~W~).~:@>"
'(main boston))
Main street
goes to
Boston.
To a considerable extent, the basic form of the directive ~<...~> is
incompatible with the dynamic control of the arrangement of output by ~W,
~_, ~<...~:>, ~I, and ~:T. As a result, it is an error for any of these
directives to be nested within ~<...~>. Beyond this, it is also an error
for the ~<...~:;...~> form of ~<...~> to be used at all in conjunction with
any of these directives.
!
~I [format directive]
INDENT -- ~nI specifies that the indentation within the immediately
containing logical block should be set to the column position of the
first character in the block plus n ems. If omitted, n defaults to
zero. The parameter can be negative; however, the total indentation
cannot be moved left of the beginning of the line or left of the end of
the rightmost per-line prefix. ~n:I is exactly the same as ~nI except
that it operates relative to the position in the output of the directive
itself, rather than relative to the first character in the block. (For
robustness in the face of variable-width fonts, it is advisable to use
~:I with a parameter of zero instead of ~I whenever possible.) Changes
in indentation caused by a ~I directive do not take effect until after
the next line break. Consider the following example:
(format T #"~:<~W ~@_~:I~W ~:_~W ~1I~_~W~:>"
'(defun prod (x y) (* x y)))
If the line width available is 15, both the ~:_ and the ~_ are replaced by
line breaks. The ~:I directive before the ~W that prints the function name
causes the argument list to be lined up under the function name. The ~1I
directive before the ~_ specifies that the statement in the body of the
DEFUN should be printed at a relative indentation of 1 in the logical
block.
(DEFUN PROD
(X Y)
(* X Y))
In miser style, all ~I directives are ignored, forcing the lines
corresponding to the logical block to line up under the first character in
the block. If *PRINT-MISER-WIDTH* were greater than or equal to 14 (the
block begins in the second column, after the prefix "(" IS printed), the
example output above would have been as follows.
(DEFUN
PROD
(X Y)
(* X Y))
~:T [format directive]
TABULATE -- If the colon modifier is used with the ~T directive, the
tabbing computation is done relative to the column where the section
immediately containing the directive begins, rather than with respect to
column zero. The numerical parameters are both interpreted as being in
units of ems. Consider the following example. Each street name is
followed by a ~8:T, which ensures that the total width taken up will be
a multiple of 8. With a line width of 25, the output shown is produced.
(format T #"~<Roads ~:I~@_~@{~W~↑~8:T~:_~}~:>"
'(elm main maple center))
Roads ELM MAIN
MAPLE CENTER
!
~/name/ [format directive]
CALL FUNCTION -- User defined functions can be called from within a FORMAT
string by using the directive ~/name/. The colon modifier, the atsign
modifier, and arbitrarily many parameters can be specified with the ~/name/
directive. The name can contain a package prefix, but it cannot contain
"/". If the readmacro #"..." is used, the default package associated with
name will be the value of *PACKAGE* at the moment the #"..." is read. If
an ordinary FORMAT control string is used, the default package will be the
value of *PACKAGE* at the moment the string is processed by FORMAT.
When a ~/name/ directive is encountered, the indicated function is called
with four or more arguments. The first four arguments are: the output
stream, the FORMAT argument corresponding to the directive, the value T if
the colon modifier was used (NIL otherwise), and the value T if the atsign
modifier was used (NIL otherwise). The remaining arguments consist of any
parameters specified with the directive. The function should print the
argument appropriately. Any values returned by the function are ignored.
~/LINEAR-STYLE/ [format directive]
An argument, a list, is printed so that either all of the elements are on
one line or each element is on a separate line. Parentheses are printed
around the list if the colon modifier is specified. As an example of a
function intended to be called from within a FORMAT string, the definition
of LINEAR-STYLE is shown below.
(defun linear-style (stream list &optional (colon? T) atsign?)
(declare (ignore atsign?))
(if colon?
(format stream #"~:<~@{~W~↑ ~_~}~:>" list)
(format stream #"~<~@{~W~↑ ~_~}~:>" list)))
~/FILL-STYLE/ [format directive]
An argument, a list, is printed with as many elements as possible on each
line. Parentheses are printed around the list if the colon modifier is
specified.
~/TABULAR-STYLE/ [format directive]
An argument, a list, is printed in a tabular form with as many elements as
possible on each line. In addition to the colon modifier, which causes
parentheses to be printed, ~/TABULAR-STYLE/ takes a parameter
(default 16) that specifies the width in ems of columns in the table.
!
Functional Interface
The primary interface to operations for dynamically determining the
arrangement of output is provided through FORMAT. This is done,
because FORMAT strings are typically the most convenient way of
interacting with pretty printing. However, these operations have
nothing inherently to do with FORMAT per se. In particular, they can
also be accessed via the six functions and macros below.
WITHIN-LOGICAL-BLOCK (STREAM-SYMBOL LIST [Macro]
:PREFIX :PER-LINE-PREFIX :SUFFIX)
&BODY BODY
In the manner of ~<...~:>, this macro causes printing to be
grouped into a logical block. The value NIL is always returned.
STREAM-SYMBOL must be a symbol. If it is NIL, it is treated the same as
if it were *STANDARD-OUTPUT*. If it is T, it is treated the same as if
it were *TERMINAL-IO*. The run-time value of STREAM-SYMBOL must be a
stream. The logical block is printed into this destination stream.
The BODY can contain any arbitrary Lisp forms. Within the BODY,
STREAM-SYMBOL is bound to a special kind of stream that supports dynamic
decisions about the arrangement of output and then forwards the output
to the destination stream. All the standard printing functions (e.g.,
WRITE, PRINC, TERPRI) can be used to print output into STREAM-SYMBOL.
All and only the output sent to STREAM-SYMBOL is treated as being in the
logical block. (It is an error to send any output directly to the
underlying destination stream.)
The :SUFFIX, :PREFIX, and :PER-LINE-PREFIX must all be expressions that
(at run time) evaluate to strings. :SUFFIX (which defaults to the null
string) specifies a suffix that is printed just after the logical block.
:PREFIX specifies a prefix to be printed before the beginning of the
logical block. :PER-LINE-PREFIX specifies a prefix that is printed
before the block and at the beginning of each new line in the block. It
is an error for :PREFIX and :PRE-LINE-PREFIX to both be used. If neither
is used, a :PREFIX of the null string is assumed.
LIST is interpreted as being a list that BODY is responsible for
printing. If LIST does not (at run time) evaluate to a list, it is
printed using WRITE. If *PRINT-CIRCLE* is not NIL and LIST is a
circular reference to a cons, then an appropriate #n# marker is printed.
If *PRINT-LEVEL* is not NIL and the logical block is at a dynamic
nesting depth of greater than *PRINT-LEVEL* in logical blocks, # is
printed. If either of the three conditions above occures, the indicated
special output is printed on STREAM-SYMBOL and the BODY is skipped along
with the printing of the prefix and suffix. (If the BODY is
not responsible for printing a list, then the first two tests above can
be turned off by supplying NIL for the LIST argument.)
!
CONDITIONAL-NEWLINE KIND &OPTIONAL (STREAM *STANDARD-OUTPUT*) [Function]
CONDITIONAL-NEWLINE is the functional equivalent of ~_. STREAM (which
defaults to *STANDARD-OUTPUT*) follows the standard conventions for
stream arguments to printing functions (i.e., NIL stands for
*STANDARD-OUTPUT* and T stands for *TERMINAL-IO*). The KIND argument
specifies the style of conditional newline. It must be one of :LINEAR,
:FILL, :MISER, or :MANDATORY. If STREAM is a special stream bound by
WITHIN-LOGICAL-BLOCK, a conditional newline is sent to it. Otherwise,
CONDITIONAL-NEWLINE has no effect. The value NIL is always returned.
LOGICAL-BLOCK-INDENT RELATIVE-TO N &OPTIONAL (STREAM *STANDARD-OUTPUT*) [Function]
LOGICAL-BLOCK-INDENT is the functional equivalent of ~I. STREAM (which
defaults to *STANDARD-OUTPUT*) follows the standard conventions for
stream arguments to printing functions. N specifies the indentation in
ems. If RELATIVE-TO is :BLOCK, this indentation is relative to the
start of the enclosing block (as for ~I). If RELATIVE-TO is :CURRENT,
the indentation is relative to the current output position (as for ~:I).
It is an error for RELATIVE-TO to take on any other value. If STREAM is
a special stream bound by WITHIN-LOGICAL-BLOCK, LOGICAL-BLOCK-INDENT
sets the indentation in the innermost enclosing logical block.
Otherwise, LOGICAL-BLOCK-INDENT has no effect. The value NIL is always
returned.
LOGICAL-BLOCK-TAB KIND COLNUM COLINC &OPTIONAL (STREAM *STANDARD-OUTPUT*)
LOGICAL-BLOCK-TAB is the functional equivalent of ~T. STREAM (which
defaults to *STANDARD-OUTPUT*) follows the standard conventions for
stream arguments to printing functions. The arguments COLNUM and COLINC
correspond to the two numeric parameters to ~T and are in terms of ems.
The KIND argument specifies the style of tabbing. It must be one of
:LINE (tab using ~T), :BLOCK (tab using ~:T), :LINE-RELATIVE (tab using
~@T), or :BLOCK-RELATIVE (tab using ~:@T). If STREAM is a special
stream bound by WITHIN-LOGICAL-BLOCK, tabbing is performed. Otherwise,
LOGICAL-BLOCK-TAB has no effect. The value NIL is always returned.
LOGICAL-BLOCK-POP ARGS &OPTIONAL (STREAM *STANDARD-OUTPUT*) [Macro]
LOGICAL-BLOCK-COUNT &OPTIONAL (STREAM *STANDARD-OUTPUT*) [Macro]
LOGICAL-BLOCK-POP is identical to POP except that it supports
*PRINT-LENGTH* and *PRINT-CIRCLE*. It is an error to use
LOGICAL-BLOCK-POP anywhere other than syntactically nested within a
call on WITHIN-LOGICAL-BLOCK.
ARGS must be a symbol or expression acceptable to POP. STREAM (which
defaults to *STANDARD-OUTPUT*) follows the standard conventions for
stream arguments to printing functions. If STREAM is a special stream
bound by WITHIN-LOGICAL-BLOCK, then LOGICAL-BLOCK-POP performs the
special operations described below. Otherwise, LOGICAL-BLOCK-POP is
identical to POP.
!
Each time LOGICAL-BLOCK-POP is called, it performs three tests. if
ARGS is not a cons, ". " is printed followed by ARGS. If
*PRINT-LENGTH* is NIL and LOGICAL-BLOCK-POP has already been called
*PRINT-LENGTH* times within the immediately containing logical block,
"..." is printed. If *PRINT-CIRCLE* is not NIL, and ARGS is a circular
reference, then ". " is printed followed by an appropriate #n# marker.
If either of the three conditions above occurs, the special output is
printed on :STREAM and the execution of the immediately containing
WITHIN-LOGICAL-BLOCK is terminated except for the printing of the
suffix. Otherwise, LOGICAL-BLOCK-POP pops the top value off of ARGS
and returns this value.
LOGICAL-BLOCK-COUNT is identical to LOGICAL-BLOCK-POP except that it
does not take an ARGS argument, always returns NIL, and only performs
the second test discussed above. It is useful when the components of a
non-list are being printed.
Using the functions above, TABULAR-STYLE could be defined as follows.
(defun tabular-style (s list &optional (colon? T) atsign? (tabsize nil))
(declare (ignore atsign?))
(if (null tabsize) (setq tabsize 16))
(within-logical-block (s list :prefix (if colon? "(" "")
:suffix (if colon? ")" ""))
(when list
(loop (write (logical-block-pop list s) :stream s)
(if (null list) (return nil))
(write-char #\space s)
(logical-block-tab :block-relative 0 tabsize s)
(conditional-newline :fill s)))))
The function below prints a vector using #(...) notation.
(defun print-vector (v *standard-output*)
(within-logical-block (nil nil :prefix "#(" :suffix ")")
(let ((end (length v)) (i 0))
(when (plusp end)
(loop (logical-block-count)
(write (aref v i))
(if (= (incf i) end) (return nil))
(write-char #\space)
(conditional-newline :fill))))))
FILL-STYLE STREAM LIST &OPTIONAL (COLON? T) ATSIGN?
LINEAR-STYLE STREAM LIST &OPTIONAL (COLON? T) ATSIGN?
TABULAR-STYLE STREAM LIST &OPTIONAL (COLON? T) ATSIGN? (TABSIZE 16)
The directives ~/fill-style/, ~/linear-style/, and ~/tabular-style/ are
supported by the three functions above. These functions can also be
called directly by the user. Each function prints parentheses around
the output if an only if COLON? (default T) is not NIL. Each function
ignores its ATSIGN? argument and returns NIL. (These arguments are
optional to facilitate the direct use of the three functions.) Each
function handles abbreviation and circularity detection correctly, and
uses WRITE to print LIST when given a non-list argument.
The function LINEAR-STYLE prints a list either all on one line, or with
each element on a separate line. The function FILL-STYLE prints a list
with as many elements as possible on each line. The function
TABULAR-STYLE is the same as FILL-STYLE except that it prints the
elements so that they line up in columns. This function takes an
additional argument TABSIZE (default 16) that specifies the column
spacing in ems.
!
Print Dispatch Tables
Pretty printing is directed by print dispatch tables.
COPY-PRINT-DISPATCH &optional (table *PRINT-DISPATCH*) [function]
A copy is made of table, which defaults to the current print dispatch
table. If table is NIL, a copy is made of the initial print dispatch
table.
DEFINE-PRINT-DISPATCH type-specifier options &body function [macro]
This puts an entry into a print dispatch table. The type-specifier
(which is implicitly quoted) is the key of the entry. The function
specifies how to pretty print the indicated type of object. When
appropriate, the function is called with two arguments: an output
stream and the object to print. Any values returned by the function are
ignored. The options are a list of pairs containing a keyword and a
value. Three different keywords are supported:
(:TABLE table)
Specifies the table (default *PRINT-DISPATCH*) to put the dispatch entry
into.
(:PRIORITY number)
Specifies a priority (default 0) used to resolve conflicts when an object
matches more than one entry.
(:NAME name)
Specifies a name to be given to function. This makes it possible to
reuse the function---e.g., in another call on DEFINE-PRINT-DISPATCH.
Before doing anything else, DEFINE-PRINT-DISPATCH removes any existing
entry with a type specifier EQUAL to the given type specifier. A new
entry containing the given priority and function is then created.
The function in a DEFINE-PRINT-DISPATCH call can be specified in five
different ways. First, the function can be NIL. In this case, no new
entry is made after the old entry (if any) is removed. Second, the
function can be omitted altogether. In this case, the standard pretty
printing function (if any) corresponding to the type specifier is entered
into the table. Third, the function can be an argument list followed by a
body consisting of one or more statements. (The use of &REST X in the
argument list below makes it possible to use ~/RATIO-PRINT/ in a FORMAT
string.)
(define-print-dispatch ratio ((:name ratio-print))
(s obj &rest x)
(declare (ignore x))
(format s #"#.(/ ~W ~W)" (numerator obj) (denominator obj)))
(pprint '(2/3 -4/5)) prints: (#.(/ 2 3) #.(/ -4 5))
!
Fourth, the function can be an instance of #"...".
(define-print-dispatch (and ratio (satisfies plusp))
((:priority 1))
#"(+ ~/ratio-print/)")
(pprint '(2/3 -4/5)) prints: ((+ #.(/ 2 3)) #.(/ -4 5))
Fifth, the function can be a sharp-quoted function name. The definition
below shows the default method used for printing lists that represent data,
rather than programs. (As shown in the definition of LINEAR-STYLE above,
LINEAR-STYLE, FILL-STYLE, and TABULAR-STYLE are all defined with their
COLON? and ATSIGN? arguments optional so that they can be used as
DEFINE-PRINT-DISPATCH functions.)
(define-print-dispatch cons ((:priority -10)) #'fill-style)
The entry to use for printing an object is selected by looking at the
entries in *PRINT-DISPATCH* in the order of their priorities. The first
entry whose type specifier matches the object is chosen. If an object
matches two entries with the same priority, an arbitrary choice is made.
If no entry matches the object, the object is printed as if *PRINT-PRETTY*
were NIL.
(CONS car-type cdr-type) [type specifier]
When used simply as the symbol CONS, this type specifier matches any
cons cell. When used in the form above, it matches a cons cell only if the
car of the cell matches the type specifier car-type and the cdr of
the cell matches the type specifier cdr-type. The cdr-type can
be omitted in which case it defaults to T.
The examples below show three of the predefined pretty printing functions
for Lisp code. By default, function calls are printed in the standard
way---i.e, either all on one line or with the arguments one to a line
indented after the function name.
(define-print-dispatch (cons (and symbol (satisfies fboundp)))
((:priority -5))
#"~:<~W~↑ ~:I~@_~@{~W~↑ ~_~}~:>")
Lists beginning with COND are printed the same way as function calls,
except that the clauses are always printed in linear style, rather than in
the format suggested by their cars.
(define-print-dispatch (cons (member cond)) ()
#"~:<~W~↑ ~:I~@_~@{~:/linear-style/~↑ ~_~}~:>")
Lists beginning with QUOTE are printed using the standard "'" syntax. Note
the care taken to ensure that data lists that happen to begin with QUOTE
will be printed legibly.
(define-print-dispatch (cons (member quote)) () (s list)
(if (and (consp (cdr list)) (null (cddr list)))
(format s #"'~W" (cadr list))
(fill-style s list)))
!
In addition to the last four entries shown above, the initial print
dispatch table contains approximately fifty additional entries with type
specifiers of the form (CONS (MEMBER symbol)) and priority zero for various
Lisp special forms and macros. There are no other predefined pretty
printing functions for data structures other than lists. However, as shown
below, such entries can easily be defined.
(defstruct family mom kids)
(define-print-dispatch family () (s f)
(format s #"~@<#<~;~W and ~2I~_~/fill-style/~;>~:>"
(family-mom f) (family-kids f)))
The pretty printing function for the structure FAMILY specifies how to
adjust the layout of the output so that it can fit aesthetically into a
variety of line widths. In addition, it obeys the printer control
variables *PRINT-LEVEL*, *PRINT-LENGTH*, *PRINT-LINES*, *PRINT-CIRCLE*, and
*PRINT-ESCAPE*, and can tolerate several different kinds of malformity in
the data structure. The output below shows what happens with line width
25, *PRINT-PRETTY T, *PRINT-ESCAPE* NIL, and a malformed KIDS list.
(write (list 'principle-family
(make-family :mom "Lucy"
:kids '("Mark" "Bob" . "Dan"))))
(PRINCIPLE-FAMILY
#<Lucy and
Mark Bob . Dan>)
Note that a pretty printing function for a structure is different from the
structure's print function. While print functions are permanently
associated with a structure, pretty printing functions are stored in print
dispatch tables and can be rapidly changed to reflect different printing
needs. If there is no pretty printing function for a structure in the
current print dispatch table, the print function (if any) is used instead.
[End of attached document]
∂22-Mar-89 1104 CL-Cleanup-mailer Issue: ADJUST-ARRAY-NOT-ADJUSTABLE (Version 9)
Received: from Think.COM by SAIL.Stanford.EDU with TCP; 22 Mar 89 11:01:59 PST
Received: from fafnir.think.com by Think.COM; Wed, 22 Mar 89 13:05:17 EST
Return-Path: <gls@Think.COM>
Received: from verdi.think.com by fafnir.think.com; Wed, 22 Mar 89 12:56:48 EST
Received: by verdi.think.com; Wed, 22 Mar 89 12:53:33 EST
Date: Wed, 22 Mar 89 12:53:33 EST
From: Guy Steele <gls@Think.COM>
Message-Id: <8903221753.AA26200@verdi.think.com>
To: Moon@stony-brook.scrc.symbolics.com
Cc: cl-cleanup@sail.stanford.edu
In-Reply-To: David A. Moon's message of Tue, 21 Mar 89 19:28 EST <19890322002858.7.MOON@EUPHRATES.SCRC.Symbolics.COM>
Subject: Issue: ADJUST-ARRAY-NOT-ADJUSTABLE (Version 9)
After yet more careful study I conclude that the version 9 proposal
is not a clarification but a change. Here is the reasoning.
There is only one way in Common Lisp to adjust an array, and that is by
calling ADJUST-ARRAY. (The definition of VECTOR-PUSH-EXTEND, p. 296,
specifically says that it uses ADJUST-ARRAY, and other places in the
language, such as FORMAT with a string as first argument, refer to
VECTOR-PUSH-EXTEND.)
Hence it is senseless to speak of an array that is "adjustable" but cannot
under any circumstances legitimately be given to ADJUST-ARRAY.
Now look at the definition of ADJUST-ARRAY, pp. 297-98.
It is not permitted to call ADJUST-ARRAY on an array that was not
created with the :ADJUSTABLE option. The predicate ADJUSTABLE-ARRAY-P
may be used to determine whether or not an array is adjustable.
I reason that the first sentence prohibits any array not created with
the :ADJUSTABLE option from being given to ADJUST-ARRAY under any
circumstances. This includes having been tested with ADJUSTABLE-ARRAY-P.
Therefore any array not created with the :ADJUSTABLE option must be
not adjustable. Therefore ADJUSTABLE-ARRAY-P must return NIL when
given such an array. Therefore the following items of the proposal
cannot be true of the current (CLtL) specification:
1. ... Whether ADJUSTABLE-ARRAY-P is
true of some other arrays is unspecified.
b. There is no specified way to create an array for which ADJUSTABLE-ARRAY-P
definitely returns NIL.
Therefore the proposal is a change and not a clarification, and
should be labeled as such.
----------------------------------------------------------------
I think that the following points also require clarification or comment:
(1) What is a compiler permitted to conclude from the declarations
(DECLARE (SIMPLE-ARRAY FOO)
(TYPE (AND ARRAY (NOT SIMPLE-ARRAY)) BAR))
?
(2) What is a program permitted to conclude from the test
(TYPEP X 'SIMPLE-ARRAY)
both when it returns true and when it returns false?
(3) I believe that much of the controversy stems from disagreement over
whether the definition on page 28 is considered to be an implication
or an equivalence. That is, I think everyone agrees that the
sentence could be rephrased as:
An array is simple __________ it is is not displaced to another
array, has no fill pointer, and is not adjustable.
but they disagree on whether the blank should read "if" or "iff".
The proposal should state explicitly which of these two interpretations
(or what third interpretation) is assumed.
--Guy
∂22-Mar-89 1612 CL-Cleanup-mailer Issue: PRETTY-PRINT-INTERFACE, version 4
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 22 Mar 89 16:11:53 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 563289; Wed 22-Mar-89 19:11:28 EST
Date: Wed, 22 Mar 89 19:11 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: PRETTY-PRINT-INTERFACE, version 4
To: dick@wheaties.ai.mit.edu
cc: cl-cleanup@SAIL.STANFORD.EDU
In-Reply-To: <8903221854.AA10669@wheat-chex.ai.mit.edu>
Message-ID: <19890323001116.9.MOON@EUPHRATES.SCRC.Symbolics.COM>
Version 4 of the proposal looks good to me. I noticed one typo,
in the arguments of WITHIN-LOGICAL-BLOCK the word &KEY is missing.
I still think that the FORMAT-based interface and the functional
interface should be separated for voting purposes.
∂22-Mar-89 2239 CL-Cleanup-mailer Issue: PATHNAME-SUBDIRECTORY-LIST (Version 4)
Received: from moon.src.honeywell.com (ALTURA.HONEYWELL.COM) by SAIL.Stanford.EDU with TCP; 22 Mar 89 22:39:31 PST
Return-Path: <alarson@src.honeywell.com>
Received: from pavo.SRC.Honeywell.COM by moon.src.honeywell.com (5.59/smail2.6.3/06-17-88);
Thu, 23 Mar 89 00:40:28 CST id AA25401 for cl-cleanup@SAIL.STANFORD.EDU
Posted-Date: Thu, 23 Mar 89 00:38:34 CST
Received: by pavo.src.honeywell.com (3.2/SMI-3.2)
id AA25833; Thu, 23 Mar 89 00:38:34 CST
Date: Thu, 23 Mar 89 00:38:34 CST
From: alarson@src.honeywell.com (Aaron Larson)
Message-Id: <8903230638.AA25833@pavo.src.honeywell.com>
To: Moon@STONY-BROOK.SCRC.Symbolics.COM
Cc: cl-cleanup@SAIL.STANFORD.EDU
In-Reply-To: David A. Moon's message of Wed, 22 Mar 89 21:59 EST <19890323025928.1.MOON@EUPHRATES.SCRC.Symbolics.COM>
Subject: Issue: PATHNAME-SUBDIRECTORY-LIST (Version 4)
Allow the value of a pathname's directory component to be a list. The
car of the list may be either of the symbols :ABSOLUTE or :RELATIVE.
Each remaining element of the list is a string or one of the keyword
symbols listed below...
I picked on Kent for not specifying that the elements of the list should be
either strings or keywords, then after reading PATHNAME-WILD, I think that
we should not preclude implmentations from defining "regular expression",
or "user home directory"components. E.g.
(pathname-directory x) => (:absolute "foo" #<regexp "Fo" :wild "bar">)
(pathname-directory x) => (#<user-homedir "alarson"> "bar" "baz")
I'm not advocating adding such a feature, just not precluding us from
defining one in the future. Perhaps we should add a line something like:
"Implementations may permit objects of types other than keywords and
strings as elements of the pathname-directory list."
Even without a statement of this kind, I support the proposal.
∂23-Mar-89 0645 CL-Cleanup-mailer Re: Issue: PATHNAME-COMPONENT-CASE (Version 2)
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 23 Mar 89 06:45:08 PST
Received: from defun.utah.edu by cs.utah.edu (5.61/utah-2.1-cs)
id AA00648; Thu, 23 Mar 89 07:45:05 -0700
Received: by defun.utah.edu (5.61/utah-2.0-leaf)
id AA12384; Thu, 23 Mar 89 07:44:50 -0700
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8903231444.AA12384@defun.utah.edu>
Date: Thu, 23 Mar 89 07:44:49 MST
Subject: Re: Issue: PATHNAME-COMPONENT-CASE (Version 2)
To: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Cc: cl-cleanup@SAIL.STANFORD.EDU
In-Reply-To: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>, Wed, 22 Mar 89 23:30 EST
[removed x3j13; added cl-cleanup]
I don't really like any of these proposals.
Proposal CANONICALIZE is broken because it doesn't provide any way to
specify that a pathname component should be in *exactly* the case you
provide (including all upper or all lower) on file systems that
support mixed case.
Proposals NEW-COMMON-ACCESSORS and NEW-LOCAL-ACCESSORS add too many
functions to the language.
Proposal KEYWORD-ARGUMENT is the least objectionable of the bunch, but
I still don't like it. I still claim that there is no portable way to
use MAKE-PATHNAME (even if the problems with case are involved),
because there are other problems with things like the lengths of
strings and what characters are valid in the various pathname fields
on different file systems.
-Sandra
-------
∂23-Mar-89 0804 CL-Cleanup-mailer Re: Issue: PATHNAME-COMPONENT-CASE (Version 2)
Received: from multimax.encore.com by SAIL.Stanford.EDU with TCP; 23 Mar 89 08:03:56 PST
Received: from mist.encore.COM by multimax.encore.com with SMTP (5.61/25-eef)
id AA10286; Thu, 23 Mar 89 11:03:37 -0500
Received: from localhost by mist. (4.0/SMI-4.0)
id AA04203; Thu, 23 Mar 89 11:05:32 EST
Message-Id: <8903231605.AA04203@mist.>
To: "sandra%defun@cs.utah.edu"@Multimax.encore.com (Sandra J Loosemore)
Cc: cl-cleanup@SAIL.STANFORD.EDU
Subject: Re: Issue: PATHNAME-COMPONENT-CASE (Version 2)
In-Reply-To: Your message of Thu, 23 Mar 89 07:44:49 -0700.
<8903231444.AA12384@defun.utah.edu>
Date: Thu, 23 Mar 89 11:05:29 EST
From: Dan L. Pierson <pierson@mist.encore.com>
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Date: Thu, 23 Mar 89 07:44:49 MST
Proposal KEYWORD-ARGUMENT is the least objectionable of the bunch, but
I still don't like it. I still claim that there is no portable way to
use MAKE-PATHNAME (even if the problems with case are involved),
because there are other problems with things like the lengths of
strings and what characters are valid in the various pathname fields
on different file systems.
Are you saying that there is no portable way to make any desired
pathname or that even if you limit your program to a "portable" subset
of file names that there is no portable way to manipulate them.
Such a portable subset might be a single alphabetic case, digits, 0 or
1 period, and no more than 14 characters total. You might be able to
add underscore are well.
∂23-Mar-89 0805 CL-Cleanup-mailer Re: Issue: PATHNAME-SUBDIRECTORY-LIST (Version 4)
Received: from multimax.encore.com by SAIL.Stanford.EDU with TCP; 23 Mar 89 08:05:17 PST
Received: from mist.encore.COM by multimax.encore.com with SMTP (5.61/25-eef)
id AA10302; Thu, 23 Mar 89 11:05:08 -0500
Received: from localhost by mist. (4.0/SMI-4.0)
id AA04217; Thu, 23 Mar 89 11:07:03 EST
Message-Id: <8903231607.AA04217@mist.>
To: cl-cleanup@sail.stanford.edu
Subject: Re: Issue: PATHNAME-SUBDIRECTORY-LIST (Version 4)
Date: Thu, 23 Mar 89 11:07:02 EST
From: Dan L. Pierson <pierson@mist.encore.com>
Date: Thu, 23 Mar 89 10:53:28 EST
From: Dan L. Pierson <pierson>
I'm not advocating adding such a feature, just not precluding us from
defining one in the future. Perhaps we should add a line something like:
"Implementations may permit objects of types other than keywords and
strings as elements of the pathname-directory list."
Even without a statement of this kind, I support the proposal.
Since we seem to be adopting an overall conformance extensions
position of "everything not explicity permitted is forbidden", I
strongly support this change. While I will probably vote for the
proposal without the change, note that raising this issue then
rejecting the change amounts to an explicit statement by X3J13 that
such extensions are prohibited. I think this would be very
unfortunate.
∂23-Mar-89 0820 CL-Cleanup-mailer Re: Issue: PATHNAME-COMPONENT-CASE (Version 2)
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 23 Mar 89 08:20:42 PST
Received: from defun.utah.edu by cs.utah.edu (5.61/utah-2.1-cs)
id AA03358; Thu, 23 Mar 89 09:20:38 -0700
Received: by defun.utah.edu (5.61/utah-2.0-leaf)
id AA12460; Thu, 23 Mar 89 09:20:35 -0700
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8903231620.AA12460@defun.utah.edu>
Date: Thu, 23 Mar 89 09:20:34 MST
Subject: Re: Issue: PATHNAME-COMPONENT-CASE (Version 2)
To: Dan L. Pierson <pierson@mist.encore.com>
Cc: cl-cleanup@SAIL.STANFORD.EDU
In-Reply-To: Dan L. Pierson <pierson@mist.encore.com>, Thu, 23 Mar 89 11:05:29 EST
> Date: Thu, 23 Mar 89 11:05:29 EST
> From: Dan L. Pierson <pierson@mist.encore.com>
>
> Are you saying that there is no portable way to make any desired
> pathname or that even if you limit your program to a "portable" subset
> of file names that there is no portable way to manipulate them.
>
> Such a portable subset might be a single alphabetic case, digits, 0 or
> 1 period, and no more than 14 characters total. You might be able to
> add underscore are well.
Yup, that's what I'm saying. We ran into this problem while trying to
port PCLS to the Cray running CTSS a few years ago. The file system
had no concept of directories or file types, and file names were
restricted to 6 characters.
Also, the Atari ST's file system (and MS-DOS also?) supports only
1-character device names, 8-character file names and 3-character file
types. As I recall, IBM's VM/CMS (and I think MVS/TSO too) delimits
the file name and file type with a space instead of a period.
-Sandra
-------
∂23-Mar-89 0919 CL-Cleanup-mailer Re: Issue: PATHNAME-COMPONENT-CASE (Version 2)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 23 Mar 89 09:18:57 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 563625; Thu 23-Mar-89 12:18:26 EST
Date: Thu, 23 Mar 89 12:18 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: Issue: PATHNAME-COMPONENT-CASE (Version 2)
To: Sandra J Loosemore <sandra%defun@CS.UTAH.EDU>
cc: cl-cleanup@SAIL.STANFORD.EDU
In-Reply-To: <8903231444.AA12384@defun.utah.edu>
Message-ID: <19890323171821.6.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Thu, 23 Mar 89 07:44:49 MST
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
I still claim that there is no portable way to
use MAKE-PATHNAME (even if the problems with case are involved),
because there are other problems with things like the lengths of
strings and what characters are valid in the various pathname fields
on different file systems.
I think there is a big difference between "it is possible to write
non-portable programs using MAKE-PATHNAME" and "it is impossible
to write any useful portable programs using MAKE-PATHNAME."
∂23-Mar-89 1112 CL-Cleanup-mailer Issue: PATHNAME-SUBDIRECTORY-LIST (Version 4)
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 23 Mar 89 11:12:20 PST
Received: from pitney-bowes ([192.9.200.50]) by heavens-gate.lucid.com id AA03428g; Thu, 23 Mar 89 11:06:43 PST
Received: by pitney-bowes id AA26285g; Thu, 23 Mar 89 11:04:50 PST
Date: Thu, 23 Mar 89 11:04:50 PST
From: Jim McDonald <jlm@lucid.com>
Message-Id: <8903231904.AA26285@pitney-bowes>
To: pierson@mist.encore.com
Cc: cl-cleanup@sail.stanford.edu
In-Reply-To: Dan L. Pierson's message of Thu, 23 Mar 89 11:07:02 EST <8903231607.AA04217@mist.>
Subject: Issue: PATHNAME-SUBDIRECTORY-LIST (Version 4)
I'm also disturbed by the proposed restrictions on the elements of a
pathname-directory list. Why, for example, is it necessary to
preclude a feature that allows variables to appear? E.g., the
following seems like a plausibly useful pair of pathnames:
(:ABSOLUTE *top-of-source-tree* "a" "b" "c")
(:ABSOLUTE *top-of-destination-tree* "a" "b" "c")
or even:
(:ABSOLUTE *top-of-source-tree* . *relative-dir-path*)
(:ABSOLUTE *top-of-destination-tree* . *relative-dir-path*)
[There's probably better syntax than a dotted pair, but you know what
I mean.]
I'm not saying I need or even want this particular feature, but I'm
pretty sure I don't want to have it prohibited just because it hadn't
occurred to anyone yet.
[Btw, I think Alarson's example for home dir could be accomomdated as
(... :HOME "alarson" ...) in the spirit of the proposal. Most
plausible structures could probably be handled similarly, but perhaps
clumsily.]
jlm
∂23-Mar-89 1132 CL-Cleanup-mailer Issue: PATHNAME-SUBDIRECTORY-LIST (Version 4)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 23 Mar 89 11:32:32 PST
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 563772; Thu 23-Mar-89 14:31:25 EST
Date: Thu, 23 Mar 89 14:31 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: PATHNAME-SUBDIRECTORY-LIST (Version 4)
To: jlm@Lucid.COM
cc: pierson@Mist.Encore.COM, CL-Cleanup@SAIL.Stanford.EDU
In-Reply-To: <8903231904.AA26285@pitney-bowes>
Message-ID: <890323143103.8.KMP@BOBOLINK.SCRC.Symbolics.COM>
Please see the issue writeup for PATHNAME-EXTENSIONS which I'm mailing out to
X3J13 in a little while. I think it is the correct way to deal with
`[not] precluding extensions.' It basically allows us to establish a model
for how CL pathnames work, and then to selectively violate that model in a
way that is detectable by portable programs. My hope is that it will allow
you to vote in favor of the PATHNAME-SUBDIRECTORY-LIST proposal in some form
(and perhaps other pathname proposals as well) without worrying that it's going
overly constrain you for some idiosyncratic feature that you wanted but couldn't
get group approval for.
∂23-Mar-89 1205 CL-Cleanup-mailer string OK for :CONC-NAME in DEFSTRUCT?
Received: from arisia (arisia.Xerox.COM) by SAIL.Stanford.EDU with TCP; 23 Mar 89 12:04:54 PST
Received: from bopp.parc.Xerox.COM by arisia with SMTP
(5.59++/IDA-1.2.6) id AA27611; Thu, 23 Mar 89 12:03:36 PST
Received: by bopp.parc.xerox.com
(5.61+/IDA-1.2.8/gandalf) id AA00266; Thu, 23 Mar 89 12:04:10 PST
Message-Id: <8903232004.AA00266@bopp.parc.xerox.com>
Reply-To: cutting.pa@bopp.parc.xerox.com
Errors-To: <postmaster@bopp.parc.xerox.com>
Date: Thu, 23 Mar 89 12:04:10 PST
From: cutting.pa@bopp.parc.xerox.com
To: cl-cleanup@SAIL.STANFORD.EDU
Cc: cutting.pa@bopp.parc.xerox.com
Subject: string OK for :CONC-NAME in DEFSTRUCT?
CLtL does not specify whether the :CONC-NAME option to DEFSTRUCT must
be a symbol, or whether strings are allowed. Its example uses a
symbol, but the default name construction for :COPIER and :PREDICATE
are described in terms of strings, providing some precedence for strings.
Xerox & Lucid allow strings, while Franz does not. Allowing strings
seems reasonable to me, as no aspect of the symbol is used except for
its name.
Has this question been addressed previously by the cleanup committee?
If not I will gladly writeup a proposal.
Doug
∂23-Mar-89 1225 CL-Cleanup-mailer Meeting 1 hour before plenary session?
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 23 Mar 89 12:25:40 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 23 MAR 89 12:21:34 PST
Date: 23 Mar 89 12:19 PST
From: masinter.pa@Xerox.COM
Subject: Meeting 1 hour before plenary session?
To: cl-cleanup@sail.stanford.edu
cc: masinter.pa@Xerox.COM
Message-ID: <890323-122134-5313@Xerox>
I'm back near a mailbox. Can we get together an hour before the main
session to go over the cleanup report agenda? I want to order the cleanup
issues so that we handle the "important" ones first. I roughly think that
means:
a) fix the cleanups that were previously broken
b) clarifications
c) changes
c) additions
within each category, order mainly by age: handle oldest issues first. But
then, there are some of these that are more 'important' that we'll want to
mess up the order.
I plan to put together a proposal for dealing with these over the next few
days and will mail it out, but you might want to come prepared with your
own list of "things that are critically important to get voted on this
meeting".
∂23-Mar-89 1504 CL-Cleanup-mailer Meeting 1 hour before plenary session?
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 23 Mar 89 12:25:40 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 23 MAR 89 12:21:34 PST
Date: 23 Mar 89 12:19 PST
From: masinter.pa@Xerox.COM
Subject: Meeting 1 hour before plenary session?
To: cl-cleanup@sail.stanford.edu
cc: masinter.pa@Xerox.COM
Message-ID: <890323-122134-5313@Xerox>
I'm back near a mailbox. Can we get together an hour before the main
session to go over the cleanup report agenda? I want to order the cleanup
issues so that we handle the "important" ones first. I roughly think that
means:
a) fix the cleanups that were previously broken
b) clarifications
c) changes
c) additions
within each category, order mainly by age: handle oldest issues first. But
then, there are some of these that are more 'important' that we'll want to
mess up the order.
I plan to put together a proposal for dealing with these over the next few
days and will mail it out, but you might want to come prepared with your
own list of "things that are critically important to get voted on this
meeting".
∂23-Mar-89 1518 CL-Cleanup-mailer Issue: READ-CASE-SENSITIVITY (Version 2)
Received: from NSS.Cs.Ucl.AC.UK by SAIL.Stanford.EDU with TCP; 23 Mar 89 15:17:15 PST
Received: from aiai.edinburgh.ac.uk by NSS.Cs.Ucl.AC.UK via Janet with NIFTP
id aa11717; 23 Mar 89 23:10 GMT
Date: Thu, 23 Mar 89 23:11:13 GMT
Message-Id: <2240.8903232311@subnode.aiai.ed.ac.uk>
From: Jeff Dalton <jeff%aiai.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK>
Subject: Issue: READ-CASE-SENSITIVITY (Version 2)
To: CL-Cleanup@sail.stanford.edu
Cc: Kent M Pitman <KMP@scrc-stony-brook.arpa>, Masinter.PA@xerox.com,
richard%aiai.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK
It's very late, but here it is.
Issue: READ-CASE-SENSITIVITY
Forum: Cleanup
References: CLtL p 334 ff: What the Read Function Accepts,
especially p 337, step 8, point 1.
CLtL p 360 ff: The Readtable
COPY-READTABLE (CLtL, p 361)
*PRINT-CASE* (CLtL, p 372)
Category: ADDITION/CHANGE
Edit history: Version 1, 15-Feb-89, by Dalton
Version 2, 23-Mar-89, by Dalton,
(completely new proposal after comments from
Pitman, Gray, Masinter, and R.Tobin@uk.ac.ed)
Problem Description:
The Common Lisp reader always converts unescaped constituent
characters to upper case. (See CLtL, p 337, step 8, point 1.)
This behavior is not always desirable.
1. Lisp applications often use the Lisp reader to read their data.
This is often significantly easier than writing input routines
from scratch, especially if the input can be structured as lists.
However, certain applications want to make use of case distinctions,
and Common Lisp makes this unreasonably difficult. (You must define
every letter as a read macro and have the macro function read the
rest of the symbol, or else you must write a reader from scratch.)
2. Some programming languages distinguish between upper and lower
case in identifiers, and useful conventions are often built around
such distinctions. For example, in C, constants are often written
in upper case and variables in lower. In Mesa(?) and Smalltalk(?),
a capital letter is used to indicate the beginning of a new word
in identifiers made up of several words. In Edinburgh Prolog,
variables begin with upper-case letters and constant symbols do
not. The case-insensitivity of the Common Lisp reader makes
it difficult to use conventions of this sort.
Proposal (READ-CASE-SENSITIVITY:READTABLE-KEYWORDS)
Define a new settable function, (READTABLE-CASE <readtable>) to
control the reader's interpretation of case. The following values
may be given:
:UPCASE -- convert unescaped characters to upper-case, as now.
:DOWNCASE -- convert unescaped characters to lower-case.
:PRESERVE -- don't convert, leaving lower-case letters in lower
case and upper-case characters in upper case.
:INVERT -- convert lower-case to upper and upper-case to lower.
COPY-READTABLE copies the setting of READTABLE-CASE. The value of
READTABLE-CASE for the standard readtable is :UPCASE.
The READTABLE-CASE of a readtable also has significance when
printing. The case in which letters are printed is determined as
follows:
When READ-CASE is :UPCASE, upper-case letters are printed in the
case specified by *PRINT-CASE*.
When READ-CASE is :DOWNCASE, lower-case letters are printed in
the case specified by *PRINT-CASE*.
When READ-CASE is :PRESERVE, letters are printed in their own
case.
When READ-CASE is :INVERT, the case of all letters is inverted.
(The behavior when *PRINT-CASE* is :CAPITALIZE is like :UPCASE for
the first character and :DOWNCASE for the rest.)
The rules for escaping letters are also affected by the READTABLE-CASE.
If *PRINT-ESCAPE* is true, letters are escaped as follows:
When READ-CASE is :UPCASE, all lower-case letters must be escaped.
When READ-CASE is :DOWNCASE, all upper-case letters must be escaped.
Otherwise, no letters need be escaped.
Proposal (READ-CASE-SENSITIVITY:READTABLE-FUNCTION)
Define a new settable function (READTABLE-CHARACTER-TRANSLATION
<readtable>) to control the reader's interpretation of unescaped
constituent characters. The value may be any function of type
(FUNCTION (CHARACTER) CHARACTER). Where the reader now converts
such characters to upper case it should instead call the function
that is the value of READTABLE-CHARACTER-TRANSLATION for the current
readtable. (See CLtL, page 337, step 8, point 1.)
COPY-READTABLE copies the setting of READTABLE-CHARACTER-TRANSLATION.
The value for the standard readtable is CHAR-UPCASE.
The READTABLE-CHARACTER-TRANSLATION of a readtable also has
significance when printing. The reader recognizes certain functions
which control the reader's interpretation of case and alters its
behavior accordingly. This behavior is given by the following
correspondence between functions and the keywords described above.
[This is just to avoid repeating a lot of text.]
function keyword
CHAR-UPCASE :UPCASE
CHAR-DOWNCASE :DOWNCASE
IDENTITY :PRESERVE
CHAR-INVERT-CASE :INVERT
The function can be given either as a symbol or as one of the values
#'CHAR-UPCASE, #'CHAR-DOWNCASE, #'IDENTITY, #'CHAR-INVERT-CASE.
If the READTABLE-CHARACTER-TRANSLATION is not one of the functions
listed above, letters are always printed in their own case (in
particular, *PRINT-CASE* has no effect), and all characters in
symbol names are escaped if *PRINT-ESCAPE* is true.
Define a new function CHAR-INVERT-CASE of type (FUNCTION (CHARACTER)
CHARACTER) analogous to CHAR-UPCASE and CHAR-DOWNCASE. It attempts
to convert its argument to upper-case if the argument is lower-case
and to lower-case if the argument is upper-case.
Rationale:
There are a number of different ways to achieve case-sensitivity.
These proposals are fairly simple but provide all of the
functionality that one could reasonably expect.
By using a property of the readtable, we avoid introducing a new
special variable. Any code that wishes to control all of the
reader's parameters already takes *READTABLE* into account. A new
special variable would require such code to change.
:DOWNCASE is included for symmetry with :UPCASE. :INVERT is
included so that case conventions could be used in Common Lisp code
without requiring that the names symbols in the "LISP" package be
written in upper case. (Opinions vary as to whether is is advisable
to use such conventions, but this proposal leaves that choice to the
user.)
In order to avoid complex interactions between the case setting of
the readtable and *PRINT-CASE*, this proposal specifies a
significance for *PRINT-CASE* only when the case setting is :UPCASE
or :DOWNCASE. The meaning of *PRINT-CASE* when the readtable
setting is :DOWNCASE was chosen for its simplicity and for symmetry
with :UPCASE while still being useful.
Test Case:
;; keyword version
(let ((rt (copy-readtable nil)))
(mapcar
#'(lambda (case)
(setf (readtable-case rt) case)
(read-from-string "Zebra"))
'(:upcase :downcase :preserve :invert)))
=> (ZEBRA |zebra| |Zebra| |zEBRA|) ;as printed with the standard
;readtable and *print-case* :upcase
Current Practice:
While there may not be any current implementation that supports
exactly this proposal, several implementations provide some means
for changing case sensitivity.
Franz Inc's ExCL has a function, EXCL:SET-CASE-MODE, that sets both
the "preferred case" (the case of character in the print names of
standard symbols such as CAR) and whether or not the reader is case-
sensitive.
In Symbolics Common Lisp, the function SET-CHARACTER-TRANSLATION
can be used to make the translation of a letter be that same letter,
thus achieving case-sensitivity.
Xerox Medley has a function for setting a readtable flag that
determines case sensitivity.
Cost to Implementors:
Fairly small. The reader will be slightly slower and readtables
will be slightly more complex.
Cost to Users:
Slight. Programmers must already take into account the possibility
that *READTABLE* will be a non-standard readtable. Case-sensitivity
is no worse than character macros in this respect.
Cost of Non-Adoption:
Applications that want to read mixed-case expressions will not
be able to use the Common Lisp reader to do so (except, perhaps,
by tortuous use of read macros).
Programming styles that rely on case distinctions (without escape
characters) will be effectively impossible in Common Lisp.
Benefits:
Applications will be able to read mixed-case expressions.
Programmers will be able to make use of case distinctions.
Aesthetics:
For the proposals:
The language will have greater symmetry, because it will be
possible to control the treatment of case on both input and output
instead of only on output (as is now the case).
The language will look less old-fashioned.
Against the proposals:
It is, perhaps, inconsistent to control case-sensitivity by a
readtable operation when other aspects of the reader, such as the
input base and the default float format (not to mention the
package), are controlled by special variables. However, it can be
argued that character-level syntax is determined chiefly by the
readtable. Case-sensitivity can be seen as analogous to character
macros in this respect.
Keywords vs function
The keyword proposal is somewhat simpler and avoids raising the
possibility of character translation that applies in general and
not just for unescaped constituents.
The function proposal is perhaps more elegant.
Discussion:
Dalton supports both proposals but slightly prefers READTABLE-CASE.
Version 1 of the proposal suggested a new global variable rather
than a property of the readtable. Pitman was strongly opposed to
that proposal and gave convincing arguments that it should be
dropped. Gray suggested that the readtable property should be a
function.
∂23-Mar-89 1534 CL-Cleanup-mailer Re: New cleanup issues
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 23 Mar 89 15:32:34 PST
Received: from Semillon.ms by ArpaGateway.ms ; 23 MAR 89 13:01:56 PST
Date: 23 Mar 89 13:01 PST
From: masinter.pa@Xerox.COM
Subject: Re: New cleanup issues
In-reply-to: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>'s message
of Tue, 21 Mar 89 18:01 EST
To: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
cc: Masinter.pa@Xerox.COM, CL-Cleanup@SAIL.STANFORD.EDU
Message-ID: <890323-130156-5430@Xerox>
Thanks. I'm merging them into the master list, and hope to get a master
hardcopy off to Mathis sometime today...
∂23-Mar-89 1538 CL-Cleanup-mailer Re: Issue: FIXNUM-NON-PORTABLE, v.5
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 23 Mar 89 15:32:54 PST
Received: from Semillon.ms by ArpaGateway.ms ; 23 MAR 89 13:14:25 PST
Date: 23 Mar 89 13:13 PST
From: masinter.pa@Xerox.COM
Subject: Re: Issue: FIXNUM-NON-PORTABLE, v.5
In-reply-to: Guy Steele <gls@Think.COM>'s message of Mon, 20 Mar 89
11:45:31 EST
To: Guy Steele <gls@Think.COM>
cc: Moon@stony-brook.scrc.symbolics.com, masinter.pa@Xerox.COM,
cl-cleanup@sail.stanford.edu
Message-ID: <890323-131425-5460@Xerox>
Sorry, yes, I blew it. This is what I've saved as "passed":
Status: Passed Jan 89 X3J13, as amended
Issue: FIXNUM-NON-PORTABLE
References: CLtL p. 14, 34, 43, 231
Category: CHANGE, CLARIFICATION
Edit History: Version 1, 11-Jul-88, Sandra Loosemore
Version 2, 15-Sep-88, Masinter
Version 3, 23-Sep-88, Masinter
Version 4, 7-Dec-88, Masinter (two proposals)
Version 5, 16-Mar-89, Masinter (incorporate amendments)
Version 6, 17-Mar-89, Masinter (incorporate amendments correctly)
Problem Description:
Implementations of Common Lisp are required to support two disjoint
subsets of integers, fixnums and bignums, with the promise that
fixnums have a more efficient representation. However, nothing is
guaranteed about the range of integers which are fixnums: "Exactly
which integers are fixnums is implementation-dependent; typically they
will be those integers in the range -2**n to 2**n - 1, inclusive, for
some n not less than 15."
There are few uses of the fixnum type that are portable, given the
current definition. In particular, many programmers use FIXNUM type
declarations where they really mean "small integer".
While most Common Lisp implementations have a FIXNUM range
which is a subset of integers represeted and operated on most
efficiently, many also have several other subranges. The
partitioning of INTEGER into BIGNUM and FIXNUM is merely
confusing in these implementations, and not useful.
CLtL p14 and p34 disagree about BIGNUM. One says that
FIXNUM and BIGNUM are an exhaustive partition of the
integer space, the other says they might not be!
Proposal: FIXNUM-NONPORTABLE:TIGHTEN-DEFINITION
(1) Change the description of the type FIXNUM to reflect that it is
required to be a supertype of (SIGNED-BYTE 16).
(2) Define BIGNUM to be exactly (AND INTEGER (NOT FIXNUM))
(3) require that (<= ARRAY-DIMENSION-LIMIT MOST-POSITIVE-FIXNUM)
Example:
Consider an implementation with three numeric representations:
Fast (INTEGER -1024 1023)
Immediate 29 bits
Extended Multi-precision
Such an implementation would have to define
FIXNUM to be (OR Fast Immediate). BIGNUM
would then refer to multi-precision integers.
Rationale:
Many programmers already use FIXNUM to mean "small integer"; this
proposal makes this usage portable.
However, there is little portable use for the type BIGNUM, and it
is inconsistent with many current implementation techniques.
Removing it is an incompatible change for a weak reason.
Current Practice:
Xerox Common Lisp has 17-bit fixnums. Most other Common Lisp
implementations have fixnum ranges of 24 bits or larger. We know
of no implementation that currently violates the proposed minimum
size.
Several existing Common Lisp implementations have more than two
representations for integers, such that the FIXNUM/BIGNUM distinction
is confusing; they define BIGNUM to cover all of the larger number
types.
Cost to implementors:
Slight. All implementations we know of already define FIXNUMs to be at
least 16 bits.
Cost to users:
Slight.
Benefits:
The FIXNUM type specifier would have a portable interpretation.
The language would be less confusing.
Discussion:
There was little consensus on whether to leave BIGNUM in the language.
Earlier discussion of a related proposal contained several other more
controversial components (adding a constant MAX-INTEGER-LENGTH, allowing
MOST-POSITIVE-FIXNUM to be NIL as well as an integer.) This proposal
is an attempt to address the part that cleanup committee seemed to agree
on.
It is possible that an implementation have a single representation for all
integers, and no way to identify any efficient range of integers. Those
implementations might need to set MOST-POSITIVE-FIXNUM
and MOST-NEGATIVE-FIXNUM to arbitrary values, consistent with
the requirement that (SIGNED-BYTE 16) is a subtype of FIXNUM.
Other alternatives considered (and not necessarily mutually exclusive
with this proposal):
remove the FIXNUM type specifier entirely, while leaving a way
to query what is the most efficient range of integers
leave the range of FIXNUMs unconstrained and introduce a
SMALL-INTEGER type with a fixed range (but no promises about
efficiency) .
It might be possible to specify the required performance behavior
of FIXNUMs more concretely, e.g., specify that the basic integer operations
use algorithms that are not proportional to the size of the data; it
should be just about as fast to add numbers in the middle of the fixnum
range as it is to add, say, 10 and 11. This might be a useful way to
describe
the intent of the FIXNUM range, if not its specification.
∂23-Mar-89 1538 CL-Cleanup-mailer The Revised Cleanup Issue Status List
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 23 Mar 89 15:33:50 PST
Received: from Semillon.ms by ArpaGateway.ms ; 23 MAR 89 13:44:52 PST
Date: 23 Mar 89 13:43 PST
From: masinter.pa@Xerox.COM
to: cl-cleanup@sail.stanford.edu
Subject: The Revised Cleanup Issue Status List
to: X3J13@sail.stanford.edu
Message-ID: <890323-134452-5540@Xerox>
This is the revised (as of 23-Mar-89 13:43:08) complete list of
Cleanup issues that are either:
passed: passed at *any* previous meeting, including Jan 89
pending: have been distributed for the March meeting
in progress: might possibly be distributed for the March meeting,
or that I think are worth pursuing.
Of course, some more might come up or be revived.
I think I have updated versions of all pending and passed
issues stored on arisia.xerox.com under the
clcleanup/pending
clcleanup/passed
directories respectively.
Codes:
! released for Jan 89 meeting
+ passed
* need new version
!*: released, but I know we'll need a new version
+*: passed, but need to reconsider
!*: passed, but need a new version to reconsider
!
+ ADJUST-ARRAY-DISPLACEMENT
Version 4, 23-Nov-87
Status: passed, 1988
+ ADJUST-ARRAY-FILL-POINTER
Version 1, 15-MAR-88
Status: passed, 1988
! ADJUST-ARRAY-NOT-ADJUSTABLE
Synopsis: ADJUST-ARRAY on array made with :ADJUSTABLE NIL: "an error"?
Version 4, 11-Jan-89, Released 12-Jan-89
Status: Accepted with amendments Jan 89 X3J13
Comments: amendment had wording problem.
Version 8, 11-Mar-89, Released 15-Mar-89
Version 9, 17-Mar-89, released 21-mar-89
Comments: (whew!)
Status: ready for vote
+ APPLYHOOK-ENVIRONMENT
Synopsis: remove (useless) env argument to applyhook
Version 2, 10-Jan-89, Released 10-Jan-89
Status: Passed Jan-89 X3J13
+ AREF-1D
14-NOV-87, Version 7
Status: Passed, 1988?
+ ARGUMENTS-UNDERSPECIFIED
Synopsis: Clarify various ranges missing from CLtL
Version 4, 21-Sep-88, Released 4 Dec 88
Status: Passed Jan 89 X3J13
+ ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS
Synopsis: What do array element-type declarations mean?
Version 9, 31-Oct-88, Released 5 Dec 88
Status: Passed Jan 89 X3J13
+ ASSOC-RASSOC-IF-KEY
Version 4, 23-NOV-87
Status: Passed, 1988?
! BREAK-ON-WARNINGS-OBSOLETE
Synopsis: deprecate *BREAK-ON-WARNINGS* because of *BREAK-ON-SIGNALS*
Version 1, 07-Mar-89, Released 15-Mar-89
Comment: leaves out a case
Status: ready for vote
! CLOS-CONDITIONS
Version 4, 10-Mar-89
Comments: define metaclass of conditions?
Status: pending
+ CLOSE-CONSTRUCTED-STREAMS
Synopsis: What does it mean to CLOSE a constructed stream?
Version 2, 12-Jan-89, Released 12-Jan-89
Status: Proposal ARGUMENT-STREAM-ONLY passed Jan 89 X3J13
!+ CLOSED-STREAM-OPERATIONS
Synopsis: What operations are legal on closed streams?
Version 5, 5-Dec-88, released 5-Dec-88
Status: amended at meeting
Version 7, 14-Feb-89
Status: Passed, as amended, Jan 89 X3J13
Comment: amendment bad; reconsider version 5.
say that INPUT-STREAM-P and OUTPUT-STREAM-P
are undefined on closed streams?
! COERCE-INCOMPLETE
Synopsis: Extend COERCE
Version 3, 7-Mar-89, Released 14-Mar-89
Status: ready for voting
+ COLON-NUMBER
Synopsis: :123 is an error
22-OCT-87, Version 1
Status: Passed, 1988?
! COMMON-TYPE
Version 1, 20-Mar-89, released 21-Mar-89
Status: vote
! COMPLEX-RATIONAL-RESULT
Version 1, 20-Mar-89, released 21-Mar-89
Status: vote
+ COMPILER-WARNING-STREAM
Version 6, 5-JUN-87
Status: Passed, 1988?
+ COMPLEX-ATAN-BRANCH-CUT
Synopsis: tweak upper branch cut in ATAN formula
Version 1, 13-Dec-88, Released 10-Jan-89
Status: Passed Jan 89 X3J13
!* CONDITION-RESTARTS
Synopsis: can't know whether restart is associated with signalling
Version 1, 18-Jan-89, released 16-Mar-89
Comment: (proposed amendments)
Status: need new version
+ CONTAGION-ON-NUMERICAL-COMPARISONS
Version 1, 14-Sep-88, Released 6 Oct 88
Status: passed, Jan 89 X3J13
! COPY-SYMBOL-COPY-PLIST
Version 1, 10-Jan-89, released 16-Mar-89
Status: ready for vote
! COPY-SYMBOL-PRINT-NAME
Version 2, 15-Mar-89, released 16-Mar-89
Status: ready for vote
+ DATA-TYPES-HIERARCHY-UNDERSPECIFIED
4-SEP-88 Version 2
Status: Passed, 1988?
+ DECLARATION-SCOPE
Version 4, 15-Nov-88, Released 9-Dec-88
Status: NO-HOISTING passed Jan 89 X3J13
+ DECLARE-ARRAY-TYPE-ELEMENT-REFERENCES
Version 3, 13-Jan-89
Status: passed, Jan 89 X3J13
+ DECLARE-FUNCTION-AMBIGUITY
Version 4, 5-Dec-88, Released 5-Dec-88
Status: passed, Jan 89 X3J13
+ DECLARE-MACROS
5-FEB-88, Version 3
Status: Passed, 1988?
+ DECLARE-TYPE-FREE
Version 10, 12-Jan-89
Status: proposal LEXICAL passed Jan 89 X3J13
+ DECODE-UNIVERSAL-TIME-DAYLIGHT
Version 2, 30-Sep-88, Released 6 Oct 88
Status: Passed, Jan 89 x3j13
* DEFMACRO-LAMBDA-LIST
Version 2, 17-Mar-89
Status: ** NEED NEW VERSION **
+ DEFPACKAGE
Version 7, 2-Nov-88, Released 5 Dec 88
Comment: clarify "at variance" in editorial work?
Status: Passed, Jan 89 X3J13
+ DEFSTRUCT-CONSTRUCTOR-KEY-MIXTURE
Version 3, 8-Jan-89, Released 11-Jan-89
Status: Passed, Jan 89 X3J13
+ DEFSTRUCT-DEFAULT-VALUE-EVALUATION
Version 1, 5/13/88
Status: Passed, 1988
+ DEFSTRUCT-PRINT-FUNCTION-INHERITANCE
Version 3, 7 Dec 88, Released 12-Dec-88
Status: Passed, Jan 89 X3J13
+ DEFSTRUCT-REDEFINITION
Synopsis: what happens if you redefine a DEFSTRUCT?
Version 3, 6-Feb-89
Status: Passed (as amended) Jan 89 X3J13
+ DEFSTRUCT-SLOTS-CONSTRAINTS-NAME
Version 5, 12-Jan-89
Status: Passed, Jan 89 X3J13
+ DEFSTRUCT-SLOTS-CONSTRAINTS-NUMBER
Version 1, 5/13/88
Status: Passed, 1988
+ DEFVAR-DOCUMENTATION
23-NOV-87, Version 2
Status: Passed, 1988?
+ DEFVAR-INIT-TIME
29-MAR-87, Version 2
Status: Passed, 1988?
+ DEFVAR-INITIALIZATION
Version 4 5-JUN-87
Status: Passed, 1988?
+ DESCRIBE-INTERACTIVE
Version 4, 15-Nov-88, Released 7-Dec-88
Synopsis: can DESCRIBE ask user a question?
Status: Proposal NO passed Jan 89 X3J13
! DESCRIBE-UNDERSPECIFIED
Version 1, 10-Mar-89, Released 16-Mar-89
Synopsis: making DESCRIBE generic was wrong; fix
Comments: "and calls DESCRIBE recursively argument if there are ... "
status: need to strike "argument"; then vote
!* DESTRUCTURING-BIND
Version 2, 25-Jan-89, Released 16-Mar-89
Synopsis: add DESTRUCTURING-BIND macro
Comments: (at end) + "can't extend by defining harmless...????"
Status: might need new version before vote
+ DISASSEMBLE-SIDE-EFFECT
Version 3 1/21/88
Status: Passed, 1988
+ DO-SYMBOLS-DUPLICATES
Version 3 23-NOV-87
Status: Passed, 1988?
+ DOTTED-MACRO-FORMS
Version 3, 15-Nov-88, Released 7-Dec-88
Status: passed, Jan 89 X3J13
+ DRIBBLE-TECHNIQUE
14-FEB-88, Version 2
Status: Passed, 1988?
! DYNAMIC-EXTENT
Version 3, 11-Jan-89, released 16-Mar-89
Comments: still some holes
Status: ready for vote?
+ EQUAL-STRUCTURE
Version 6, 11-Jan-89, Released 12-Jan-89
Status: Passed with amendments
Version 7, 15-Mar-89
Status: Passed Jan 89 X3J13 as amended.
* EQUALP-GENERIC
Version 1, 28-Feb-89
Synopsis: make EQUALP generic function
Comments: Various problems being worked on
Status: ** NEED NEW VERSION ***
* ERROR-CHECKING-IN-NUMBERS-CHAPTER
Version 1, 6-Mar-89
Synopsis: define 'should signal', 'might signal' for number fns
Status: ** NEED NEW VERSION **
! ERROR-NOT-HANDLED
Version 1, 25-Sep-88, Released 6-Oct-88 and 14-Mar-89
Status: ready for vote
+ EVAL-OTHER
8-JUN-88, Version 2
Status: Passed, 1988?
! EXIT-EXTENT
Version 6, 8-Jan-89, distributed at Jan89 X3J13
Rereleased 16-Mar-89
Status: tabled Jan89; ready for vote
+ EXPT-RATIO
Version 3, 31-Oct-88, Released 7 Dec 88
Status: passed, Jan 89 X3J13
+ FIXNUM-NON-PORTABLE
Version 4, 7-Dec-88, Released 12-Dec-88
Version 6, 17-Mar-89, as amended
Status: Passed, Jan 89 X3J13, as amended
+ FLET-DECLARATIONS
Version 2, 2 FEB 88
Status: Passed, 1988?
+ FLET-IMPLICIT-BLOCK
Version 6 5-JUN-87
Status: Passed, 1988?
+ FORMAT-ATSIGN-COLON
Version 4 5-JUN-87
Status: Passed, 1988?
+ FORMAT-COLON-UPARROW-SCOPE
Version 3, 5 FEB 88
Status: Passed, 1988?
+ FORMAT-COMMA-INTERVAL
Version 2, 15-JUN-87
Status: Passed, 1988?
+ FORMAT-E-EXPONENT-SIGN
Version 2, 2 Oct 88, Released 6 Oct 88
Status: Passed, Jan 89 X3J13
+ FORMAT-OP-C
11-JUN-87, Version 5
Status: Passed, 1988?
* FORMAT-PLURALS
Synopsis: remove ~P, add ~:@[singular~;plural~]
Status: no proposal
+ FORMAT-PRETTY-PRINT
Version 7, 15 Dec 88, Released 7 Dec 88
Comments: passed, Jan 89 X3j13
+ FUNCTION-CALL-EVALUATION-ORDER
Version 1, 22-MAR-88
Status: Passed, 1988
! FUNCTION-COERCE-TIME
Synopsis: When does SYMBOL-FUNCTION happen in MAPCAR?
Version 2, 16-sep-88, Released 8-Oct-88
Re-released: 16-Mar-89
Status: ready for vote?
+ FUNCTION-COMPOSITION
Synopsis: Add new functions
Version 5, 10-Feb-89
Status: Passed (as amended) Jan 89 X3J13
maybe this was passed as amendment to TEST-NOT-IF-NOT instead
+ FUNCTION-DEFINITION
Version 3, 10-Feb-89
Status: Passed (as amended) Jan 89 X3J13
! FUNCTION-NAME
Comment: renaming of SETF-FUNCTION-VS-MACRO, SETF-PLACES
SETF-FUNCTION-VS-MACRO
Version 3, 4-Nov-87, Released Nov 87
SETF-PLACES
Version 1, 11-Nov-88, Released 9-Dec-88
FUNCTION-NAME
Version 1, 27-Jan-89, Released 16-Mar-89
Status: ready for vote
+ FUNCTION-TYPE
Version 12, 4-SEP-88
Status: Passed, June 1988 X3J13, as amended
+ FUNCTION-TYPE-ARGUMENT-TYPE-SEMANTICS
Synopsis: Change semantics of argument types in function declarations
Version 3, 7-Dec-88, Released 12-Dec-88
Status: Passed, Jan 89 X3J13
+ FUNCTION-TYPE-KEY-NAME
Version 3, 13-FEB-88
Status: Passed, 1988
+ FUNCTION-TYPE-REST-LIST-ELEMENT
Version 5, 14-Nov-88, Released 8-Dec-88
Status: Passed, Jan 89 X3J13
! GENSYM-NAME-STICKINESS
Synopsis: no side effects if optional arg supplied
Version 1, 14-Feb-89, Released 14-Mar-89
Status: comments
Version 3, 20-Mar-89
Status: vote?
+ GET-MACRO-CHARACTER-READTABLE
Version 3, 11-Feb-89
Status: Passed (as amended) Jan 89 X3J13
+ GET-SETF-METHOD-ENVIRONMENT
Version 5 13-JUL-87
Status: Passed, 1988?
! HASH-TABLE-ACCESS
Synopsis: Add new accessors for hash-table properties
Version 1, 13-Sep-88 released 8-Oct-88
Version 2, 13 Oct 88, released 16-Mar-89
status: vote
+ HASH-TABLE-PACKAGE-GENERATORS
Version 7, 8-Dec-88, Released 9-Dec-88
Comments: The test-package-iterator example has the values
from the generator in the wrong order.
Status: passed, Jan 89 X3J13
* HASH-TABLE-PRINTED-REPRESENTATION
Version 2, 8-Jun-88
Comments: Use #S(ARRAY ...), #S(HASH-TABLE...), #S(PATHNAME...)?
Status: need new proposal
! HASH-TABLE-SIZE
Version 1, 20-Mar-89, released 21-Mar-89
+ HASH-TABLE-TESTS
Version 2, 8-Dec-88, Released 8 Dec 88
Status: passed Jan 89 X3J13
+ IEEE-ATAN-BRANCH-CUT
Version 2, 11-Jan-89, Released 11-Jan-89
Status: passed, Jan 89 X3J13
* IGNORE-VARIABLE
Synopsis: default (IGNORE IGNORE)
Version 1, 6-Feb-89
+ IMPORT-SETF-SYMBOL-PACKAGE
Version 5 ??-MAY-87
Status: Passed, 1988?
! IN-PACKAGE-FUNCTIONALITY
Version 4, 12-Dec-88, Released 12-Dec-88
Status: tabled
Version 8, 15-Mar-89, Released 15-Mar-89
Status: ready for vote
+ KEYWORD-ARGUMENT-NAME-PACKAGE
8-NOV-87, Version 8
Status: Passed, 1988?
+ LAST-N
12-MAR-88, Version 2
Status: Passed, 1988?
+ LCM-NO-ARGUMENTS
Version 1, 17 Oct 88, Released 8 Dec 88
Status: passed, Jan 89 X3J13
! LISP-PACKAGE-NAME
Synopsis: change LISP to COMMON-LISP to avoid CLtL confusion
Version 1, 22 Dec 88, Released 11-Jan-89
Status: tabled; version 1 still ready for vote
! LISP-SYMBOL-REDEFINITION
Version 5, 22-Nov-88, Released 8 Dec 88
Comments: Don't like (DEFVAR CAR ...) example
14: Like simpler "Redefining any documented
definition on a symbol in the LISP package -- such as variables,
functions, constants, properties and property-lists, etc -- is
undefined, except for the explicitly allowed cases (e.g. dynamic
binding of variables)."
Status: tabled; version 5 still ready for vote
! LOAD-OBJECTS
Synopsis: Provide a way to allow defstruct/defclass objects in compiled files
Version 3, 9-Mar-89, released 16-Mar-89
Comments: How about MAKE-LOAD-FORM-SAVING-SLOTS?
Status: ready for vote w/ name change?
! LOAD-TRUENAME
Synopsis: Make default pathname for LOAD inside LOAD same?
Version 1, 13-Mar-89, Released 16-Mar-89
Status: ready for vote
! LOCALLY-TOP-LEVEL
Version 2, 16-Mar-89, released 17-Mar-89
Status: ready to vote
! LOOP-AND-DISCREPANCY
Version 1, 15-Mar-89, released 16-Mar-89
status: ready for vote
+ MACRO-FUNCTION-ENVIRONMENT
Version 2, 8-JUN-88
Status: Passed, 1988
* MACRO-SPECIAL-FORMS
Synopsis: macros => implementation-dependent special forms doesn't work
Status: *** NEED PROPOSAL SUBMITTED ****
+ MAKE-PACKAGE-USE-DEFAULT
Version 2, 8 Oct 88, Released 12-Dec-88
Version 3, 16-Mar-89
Status: Passed, Jan 89 X3J13 as amended
! MAKE-STRING-FILL-POINTER
Synopsis: extend MAKE-STRING to take a fill-pointer?
Version 1, 20-Oct-88, released 16-Mar-89
Status: ready for vote
+ MAPPING-DESTRUCTIVE-INTERACTION
Version 2, 09-Jun-88, Released 8 Oct 88
Synopsis: [don't] define interaction of DELETE on MAPCAR'd list.
Status: passed, Jan 89 X3J13
+ NTH-VALUE
Version 4, 8-Dec-88, Released 8 Dec 88
Comment: amended to clarify when index out of range
Version 5, 17-Mar-89
Status: passed, as amended
+ PACKAGE-CLUTTER
Version 6, 12-Dec-88, Released 12-Dec-88
Comments: Accepted, with amendment
Version 7, 17-Mar-89
Status: Passed, Jan 89 X3J13, as amended
+ PACKAGE-DELETION
Version 5, 21 nov 88, Released 8 Dec 88
Comments: Minor glitches? Remove the description of "correctable" error to be signalled and
handled.
Status: passed, Jan 89 X3J13
!+ PACKAGE-FUNCTION-CONSISTENCY
Synopsis: allow strings for package arg everywhere uniformly
Version 2, 12-Jan-89, Released 12-Jan-89
Comment: Accepted MORE-PERMISSIVE with amendments
Version 3, 17-Mar-89, released 17-Mar-89
Status: vote to accept wording as intent of amendment
* PATHNAME-CANONICAL-TYPE
Synopsis: allow canonical :SOURCE-LISP to MAKE-PATHNAME;
require PATHNAME-TYPE to return same?
Version 1, 07-Jul-88
Comments: only add the :TYPE :SOURCE-LISP, not PATHNAME-CANONICAL-TYPE?
Status: => "pathname" committee?
! PATHNAME-COMPONENT-CASE
Version 2, 22-Mar-89, released 22-Mar-89
Status: vote???
! PATHNAME-COMPONENT-VALUE
Version 1, 20-Mar-89, released 21-Mar-89
Status: vote?
* PATHNAME-LOGICAL
Synopsis: add logical pathnames (pathnames for an imaginary portable
file system, which get translated by site-dependent translations into
physical pathnames on an actual file system)
Status: no proposal yet
* PATHNAME-PRINT-READ
Synopsis: Print pathnames like #P"asdf"?
Version 1, 21-Oct-88
Comments: Numerous, pro, con. Print like #S(pathname ...)?
Status: *** NEED NEW VERSION ***
+ PATHNAME-STREAM
Version 6 14-NOV-87
Status: Passed, 1988?
! PATHNAME-SUBDIRECTORY-LIST
Version 4, 22-Mar-89, released 22-mar-89
+ PATHNAME-SYMBOL
Version 5 5-FEB-88
Status: Passed, 1988?
* PATHNAME-SUBDIRECTORY-LIST
Synopsis: How to deal with subdirectory structures in pathname functions
Version 3, 29-Dec-88
Comments: typos and proposed simplifications
Status: *** NEED NEW VERSION ***
* PATHNAME-SYNTAX-ERROR-TIME
Synopsis: when are errors in pathnames detected?
Version 1, 7-Jul-88
Comments: various
Status: need new version? ==> ERRORS-IN-FILE-CHAPTERS?
+ PATHNAME-UNSPECIFIC-COMPONENT
Synopsis: More extensions to :UNSPECIFIC
Version 1, 29-Dec-88, Released 12-Jan-89
Version 2, 17-Mar-89
Status: Passed, Jan 89 X3j13, as amended
+ PEEK-CHAR-READ-CHAR-ECHO
Version 3, 8-Oct-88, Released 8 Oct 88
Synopsis: PEEK-CHAR, READ-CHAR on streams made by MAKE-ECHO-STREAM
Status: Passed, Jan 89 X3J13
* PRETTY-PRINT-INTERFACE
Version 3, 15-Mar-89
Synopsis: standardize interface to prettyprinter
Status: Need new version
+ PRINC-CHARACTER
29-APR-87, Version 2
Status: Passed, 1988?
* PRINT-CIRCLE-SHARED
Synopsis: does *PRINT-CIRCLE* cause shared structure to print with #=?
Status: Not submitted yet ** NEED WRITEUP **
+ PRINT-CIRCLE-STRUCTURE
Version 3, 20 Sep 88, Released 8 Oct 88
Comments: Accepted, with amendment
Version 4, 17-Mar-89
Status: Passed, Jan 89 X3J13, as amended
! PROCLAIM-LEXICAL
Version 9, 8-Dec-88, Released 12-Dec-88
Synopsis: add LEXICAL proclaimation
Comments: lengthy mail; amendments at Jan meeting
Status: tabled, vote on version 9 (w/o amendments)
+ PUSH-EVALUATION-ORDER
Version 5, 25-NOV-87
Status: Passed, 1988?
+ RANGE-OF-COUNT-KEYWORDS
Version 3, 9-Oct-88, Released 14-Oct-88
Status: passed, Jan 89 X3J13
+ RANGE-OF-START-AND-END-PARAMETERS
Version 1, 14-Sep-88, Released 7 Oct 88
Status: passed, Jan 89 X3J13
* READ-CASE-SENSITIVITY
Synopsis: Allow readtables to be case sensitive
Comments: use function or keyword?
Status: need new version
* READ-DELIMITED-LIST-EOF
Synopsis: eof in read deliminted list signals an error
Status: awaiting submission
! REAL-NUMBER-TYPE
Synopsis: add REAL = (OR RATIONAL FLOAT) & range
Version 3, 13-Jan-89, released 16-Mar-89
Status: vote?
+ REDUCE-ARGUMENT-EXTRACTION
Version 3 13-FEB-88
Status: Passed, 1988?
! REMF-DESTRUCTION-UNSPECIFIED
Synopsis: Specification of side-effect behavior in CL
Version 4, 29-Nov-88, Released 12-Jan-89
Status: straw vote in favor of this, BarMar will make amendments
Version 6, 17-Mar-89
Status: ready for vote?
+ REQUIRE-PATHNAME-DEFAULTS
Version 6, 9 Dec 88, Released 09 Dec 88
Status: passed, Jan 89 X3j13
+ REST-LIST-ALLOCATION
Version 3, 12-Dec-88, Released 12-Dec-88
Status: proposal MAY-SHARE passed, Jan 89 X3J13
+ RETURN-VALUES-UNSPECIFIED
Version 6, 9 Dec 88, Released 9-Dec-88
Status: passed, Jan 89 X3J13
+ ROOM-DEFAULT-ARGUMENT
Version 1, 12-Sep-88, Released 8 Oct 88
Status: passed, Jan 89 X3J13
! SETF-MULTIPLE-STORE-VARIABLES
Synopsis: Allow multiple "places" in SETF stores
Version 2, 22-Mar-89, released 22-Mar-89
Status: ready for vote?
+ SETF-SUB-METHODS
Version 5, 12-Feb-88, Released 8 Oct 88
Synopsis: careful definition of order inside (SETF (GETF ...) ...)
Status: passed, Jan 89 X3J13
+ SHADOW-ALREADY-PRESENT
Version 4 10-NOV-87
Status: Passed, 1988?
+ SHARPSIGN-PLUS-MINUS-PACKAGE
Version 3 14-NOV-87
Status: Passed, 1988?
+ SPECIAL-TYPE-SHADOWING
Synopsis: intersection of types when proclaimed special has local type
declaration
Version 1, 4-Nov-88, released 11-Jan-89
Status: passed, Jan 89 X3J13
+ STANDARD-INPUT-INITIAL-BINDING
Version 8, 8 Jul 88, Released 7 Oct 88
Status: passed, Jan 89 X3J13
+ STEP-ENVIRONMENT
Version 3, 20-Jun-88, Released 7 Oct 88
Version 4, 17-Mar-89
status: Passed, Jan 89 X3J13, as amended
+ STREAM-ACCESS
Version 2, 30-Nov-88, Released 9 Dec 88
Status: ADD-TYPES-ACCESSORS passed, Jan 89 X3J13
+ SUBSEQ-OUT-OF-BOUNDS
29-MAR-88 Version 2
Status: Passed, 1988?
* SUBTYPEP-ENVIRONMENT
Version 1, 2-Jan-89
Status: ** missing writeup ***
+ SUBTYPEP-TOO-VAGUE
Version 4, 7-Oct-88, Released 7 Oct 88
Status: passed, Jan 89 X3J13
+ SYMBOL-MACROLET-DECLARE
Version 2, 9-Dec-88, Released 9 Dec 88
Status: passed, Jan 89 X3J13
!+ SYMBOL-MACROLET-SEMANTICS
Version 5, 30-Nov-88, Released 9 Dec 88
Status: Passed, Jan 89 X3J13
Version 6, 14-Mar-89, released 16-Mar-89
Status: ready for vote
+ TAILP-NIL
Version 5, 9-Dec-88, Released 12-Dec-88
Synopsis: Operation of TAILP given NIL
Status: passed, Jan 89 X3J13
+ TEST-NOT-IF-NOT
Version 3, 1 Dec 88, Released 9 dec
Version 4, 18-Mar-89
Status: Need new version as amended.
! THE-AMBIGUITY
Version 2, 11-Jan-89, Released 11-Jan-89
Comments: typo, sense wrong
Status: tabled, vote on 2
! TIME-ZONE-NON-INTEGER
Version 1, 13-Mar-89, Released 16-Mar-89
Status: ready for vote
+* TYPE-OF-UNDERCONSTRAINED
Version 3, 12-Dec-88, Released 12 Dec 88
Comments: Accepted, with amendments
Version 5, 16-Mar-89
Comments: constraints wrong
Status: ** NEED NEW VERSION ***
! UNDEFINED-VARIABLES-AND-FUNCTIONS
Synopsis: What happens on an undefined function call, unbound variable ref?
Version 1, 29-Nov-88, Released 11-Jan-89
Comments: Lumping SLOT-UNBOUND in with unbound special variables was a mistake,
as SLOT-UNBOUND is an extension mechanism, not only a safety checking
mechanism. Also there were some wording problems. Gabriel and Gregor
are to submit a revised proposal.
No version arrived.
Status: vote on 1?
+ UNREAD-CHAR-AFTER-PEEK-CHAR
Version 2, 2-Dec-88, Released 12-Dec-88
Status: passed, Jan 89 X3J13
+ VARIABLE-LIST-ASYMMETRY
Version 3, 08-Oct-88, Released 9 Dec 88
Status: passed, Jan 89 X3J13
+ WITH-OUTPUT-TO-STRING-APPEND-STYLE
Version 5, 7-JUN-88
Status: Passed, 1988?
! WITH-OPEN-FILE-DOES-NOT-EXIST
Version 1, 17-Mar-89
Status: ready?
∂23-Mar-89 1656 CL-Cleanup-mailer Issue: READ-CASE-SENSITIVITY (Version 2)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 23 Mar 89 15:56:54 PST
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 564146; Thu 23-Mar-89 18:56:34 EST
Date: Thu, 23 Mar 89 18:56 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: READ-CASE-SENSITIVITY (Version 2)
To: jeff%aiai.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK
cc: CL-Cleanup@sail.stanford.edu, KMP@STONY-BROOK.SCRC.Symbolics.COM,
Masinter.PA@xerox.com, richard%aiai.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK
In-Reply-To: <2240.8903232311@subnode.aiai.ed.ac.uk>
Message-ID: <890323185605.7.KMP@BOBOLINK.SCRC.Symbolics.COM>
Date: Thu, 23 Mar 89 23:11:13 GMT
From: Jeff Dalton <jeff%aiai.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK>
It's very late, but here it is.
Issue: READ-CASE-SENSITIVITY
...
The write-up looks quite good to me. Even though it's late, I plan to
support it.
I prefer option READTABLE-KEYWORDS for two reasons:
(1) your recent arguments about printer issues being simpler that way
(2) the lack of need to add CHAR-INVERT-CASE (which I don't think is very
useful outside of this context).
I do want to mention that I think having an arbitrary function is not as
hard on the printer as you might expect, so I'm not sure READTABLE-FUNCTION
really needs to restrict its inputs. When the system sees an unknown
function, it could iterate over both-case-p characters, calling the function
and figuring out the mappings. Since we're talking about the system, it will
know which chars those are even in the face of international char sets.
It can determine from such a table whether the mapping is one-to-one for
a particular character (so it will know if escaping is needed) as well as
whether the mapping is case-preserving for any given character. However,
even though I think this is possible, I admit it is a pain and probably
just plain not worth the effort so I don't think it's the way to go. Based
on this, I don't really oppose READTABLE-FUNCTION, but I'd much prefer the
simpler READTABLE-KEYWORDS proposal anyway.
Btw, there may be some overlap between this and
PRINT-CASE-PRINT-ESCAPE-INTERACTION. I don't have time to check this to be
sure, but you might want to double-check to avoid last-minute snags.
∂23-Mar-89 1503 CL-Windows-mailer Issue STREAM-DEFINITION-BY-USER (V1)
Received: from ti.com by SAIL.Stanford.EDU with TCP; 23 Mar 89 09:08:32 PST
Received: by ti.com id AA12307; Wed, 22 Mar 89 21:38:08 CST
Received: from Kelvin by tilde id AA27213; Wed, 22 Mar 89 21:21:09 CST
Message-Id: <2815615116-2334006@Kelvin>
Sender: GRAY@Kelvin.csc.ti.com
Date: Wed, 22 Mar 89 21:18:36 CST
From: David N Gray <Gray@DSG.csc.ti.com>
To: CL-Cleanup@SAIL.Stanford.edu
Cc: Common-Lisp-Object-System@SAIL.Stanford.edu, CL-Windows@SAIL.Stanford.edu,
Bartley@MIPS.csc.ti.com, Waldrum@Tilde.csc.ti.com, salem@Think.COM
Subject: Issue STREAM-DEFINITION-BY-USER (V1)
Following is a more detailed write-up of the idea of a generic function
I/O interface that allows users to create their own streams. I have put
this in the format of a cleanup proposal because that seems like a good
way of presenting the information, but I realize that the timing isn't
right for including this in the standard now. Hopefully, though, this
can be used as a guideline for implementors to avoid unnecessarily
coming up with different names for the same thing, and after some
experience has been gained, this feature could be considered for
inclusion in a revision of the standard. I wanted to get this in your
hands before the X3J13 meeting in case anyone was interested in
discussing it, but I don't expect any official action to be taken.
Issue: STREAM-DEFINITION-BY-USER
References: CLtL pages 329-332, 378-381, and 384-385.
Related issues: STREAM-INFO, CLOSED-STREAM-FUNCTIONS, STREAM-ACCESS,
STREAM-CAPABILITIES
Category: ADDITION
Edit history: Version 1, 22-Mar-89 by David N. Gray
Status: For discussion and evaluation; not proposed for
inclusion in the standard at this time.
Problem description:
Common Lisp does not provide a standard way for users to define their
own streams for use by the standard I/O functions. This impedes the
development of window systems for Common Lisp because, while there are
standard Common Lisp I/O functions and there are beginning to be
standard window systems, there is no portable way to connect them
together to make a portable Common Lisp window system.
There are also many applications where users might want to define
their own filter streams for doing things like printer device control,
report formatting, character code translation, or
encryption/decryption.
Proposal STREAM-DEFINITION-BY-USER:GENERIC-FUNCTIONS
Overview:
Define a set of generic functions for performing I/O. These functions
will have methods that specialize on the stream argument; they would
be used by the existing I/O functions. Users could write additional
methods for them in order to support their own stream classes.
Define a set of classes to be used as the superclass of a stream class
in order to provide some default methods.
Classes:
The following classes are to be used as super classes of user-defined
stream classes. They are not intended to be directly instantiated; they
just provide places to hang default methods.
FUNDAMENTAL-STREAM [Class]
This class is a subclass of STREAM and of STANDARD-OBJECT. STREAMP
will return true for an instance of any class that includes this. (It
may return true for some other things also.)
FUNDAMENTAL-INPUT-STREAM [Class]
A subclass of FUNDAMENTAL-STREAM. Its inclusion causes INPUT-STREAM-P
to return true.
FUNDAMENTAL-OUTPUT-STREAM [Class]
A subclass of FUNDAMENTAL-STREAM. Its inclusion causes OUTPUT-STREAM-P
to return true. Bi-direction streams may be formed by including both
FUNDAMENTAL-OUTPUT-STREAM and FUNDAMENTAL-INPUT-STREAM.
FUNDAMENTAL-CHARACTER-STREAM [Class]
A subclass of FUNDAMENTAL-STREAM. It provides a method for
STREAM-ELEMENT-TYPE which returns CHARACTER.
FUNDAMENTAL-BINARY-STREAM [Class]
A subclass of FUNDAMENTAL-STREAM. Any instantiable class that
includes this needs to define a method for STREAM-ELEMENT-TYPE.
FUNDAMENTAL-CHARACTER-INPUT-STREAM [Class]
Includes FUNDAMENTAL-INPUT-STREAM and FUNDAMENTAL-CHARACTER-STREAM.
It provides default methods for several generic functions used for
character input.
FUNDAMENTAL-CHARACTER-OUTPUT-STREAM [Class]
Includes FUNDAMENTAL-OUTPUT-STREAM and FUNDAMENTAL-CHARACTER-STREAM.
It provides default methods for several generic functions used for
character output.
FUNDAMENTAL-BINARY-INPUT-STREAM [Class]
Includes FUNDAMENTAL-INPUT-STREAM and FUNDAMENTAL-BINARY-STREAM.
FUNDAMENTAL-BINARY-OUTPUT-STREAM [Class]
Includes FUNDAMENTAL-OUTPUT-STREAM and FUNDAMENTAL-BINARY-STREAM.
Character input:
A character input stream can be created by defining a class that
includes FUNDAMENTAL-CHARACTER-INPUT-STREAM and defining methods for the
generic functions below.
STREAM-READ-CHAR stream [Generic Function]
This reads one character from the stream. It returns either a
character object, or the symbol :EOF if the stream is at end-of-file.
Every subclass of FUNDAMENTAL-CHARACTER-INPUT-STREAM must define a
method for this function.
Note that for all of these generic functions, the stream argument
must be a stream object, not T or NIL.
STREAM-UNREAD-CHAR stream character [Generic Function]
Un-does the last call to STREAM-READ-CHAR, as in UNREAD-CHAR. Returns
NIL. Every subclass of FUNDAMENTAL-CHARACTER-INPUT-STREAM must define
a method for this function.
STREAM-READ-CHAR-NO-HANG stream [Generic Function]
This is used to implement READ-CHAR-NO-HANG. It returns either a
character, or NIL if no input is currently available, or :EOF if
end-of-file is reached. The default method provided by
FUNDAMENTAL-CHARACTER-INPUT-STREAM simply calls STREAM-READ-CHAR; this
is sufficient for file streams, but interactive streams should define
their own method.
STREAM-PEEK-CHAR stream [Generic Function]
Used to implement PEEK-CHAR; this corresponds to peek-type of NIL.
It returns either a character or :EOF. The default method
calls STREAM-READ-CHAR and STREAM-UNREAD-CHAR.
STREAM-LISTEN stream [Generic Function]
Used by LISTEN. Returns true or false. The default method uses
STREAM-READ-CHAR-NO-HANG and STREAM-UNREAD-CHAR. Most streams should
define their own method since it will usually be trivial and will
always be more efficient than the default method.
STREAM-READ-LINE stream [Generic Function]
Used by READ-LINE. A string is returned as the first value. The
second value is true if the string was terminated by end-of-file
instead of the end of a line. The default method uses repeated
calls to STREAM-READ-CHAR.
STREAM-CLEAR-INPUT stream [Generic Function]
Implements CLEAR-INPUT for the stream, returning NIL. The default
method does nothing.
Character output:
A character output stream can be created by defining a class that
includes FUNDAMENTAL-CHARACTER-OUTPUT-STREAM and defining methods for the
generic functions below.
STREAM-WRITE-CHAR stream character [Generic Function]
Writes character to the stream and returns the character. Every
subclass of FUNDAMENTAL-CHARACTER-OUTPUT-STREAM must have a method
defined for this function.
STREAM-LINE-COLUMN stream [Generic Function]
This function returns the column number where the next character
will be written, or NIL if that is not meaningful for this stream.
The first column on a line is numbered 0. This function is used in
the implementation of PPRINT and the FORMAT ~T directive. For every
character output stream class that is defined, a method must be
defined for this function, although it is permissible for it to
always return NIL.
STREAM-START-LINE-P stream [Generic Function]
This is a predicate which returns T if the stream is positioned at the
beginning of a line, else NIL. It is permissible to always return
NIL. This is used in the implementation of FRESH-LINE. Note that
while a value of 0 from STREAM-LINE-COLUMN also indicates the
beginning of a line, there are cases where STREAM-START-LINE-P can be
meaningfully implemented although STREAM-LINE-COLUMN can't be. For
example, for a window using variable-width characters, the column
number isn't very meaningful, but the beginning of the line does have
a clear meaning. The default method for STREAM-START-LINE-P on class
FUNDAMENTAL-CHARACTER-OUTPUT-STREAM uses STREAM-LINE-COLUMN, so if
that is defined to return NIL, then a method should be provided for
either STREAM-START-LINE-P or STREAM-FRESH-LINE.
STREAM-WRITE-STRING stream string &optional start end [Generic Function]
This is used by WRITE-STRING. It writes the string to the stream,
optionally delimited by start and end, which default to 0 and NIL.
The string argument is returned. The default method provided by
FUNDAMENTAL-CHARACTER-OUTPUT-STREAM uses repeated calls to
STREAM-WRITE-CHAR.
STREAM-TERPRI stream [Generic Function]
Writes an end of line, as for TERPRI. Returns NIL. The default
method does (STREAM-WRITE-CHAR stream #\NEWLINE).
STREAM-FRESH-LINE stream [Generic Function]
Used by FRESH-LINE. The default method uses STREAM-START-LINE-P and
STREAM-TERPRI.
STREAM-FINISH-OUTPUT stream [Generic Function]
Implements FINISH-OUTPUT. The default method does nothing.
STREAM-FORCE-OUTPUT stream [Generic Function]
Implements FORCE-OUTPUT. The default method does nothing.
STREAM-CLEAR-OUTPUT stream [Generic Function]
Implements CLEAR-OUTPUT. The default method does nothing.
STREAM-ADVANCE-TO-COLUMN stream column [Generic Function]
Writes enough blank space so that the next character will be written
at the specified column. Returns true if the operation is
successful, or NIL if it is not supported for this stream.
This is intended for use by by PPRINT and FORMAT ~T. The default
method uses STREAM-LINE-COLUMN and repeated calls to
STREAM-WRITE-CHAR with a #\SPACE character; it returns NIL if
STREAM-LINE-COLUMN returns NIL.
Other functions:
CLOSE stream &key abort [Generic Function]
The existing function CLOSE is redefined to be a generic function, but
otherwise behaves the same. The default method provided by class
FUNDAMENTAL-STREAM sets a flag for OPEN-STREAM-P. The value returned
by CLOSE will be as specified by the issue CLOSED-STREAM-OPERATIONS.
OPEN-STREAM-P stream [Generic Function]
This function [from proposal STREAM-ACCESS] is made generic. A
default method is provided by class FUNDAMENTAL-STREAM which returns
true if CLOSE has not been called on the stream.
STREAMP object [Generic Function]
INPUT-STREAM-P stream [Generic Function]
OUTPUT-STREAM-P stream [Generic Function]
These three existing predicates may optionally be implemented as
generic functions for implementations that want to permit users to
define streams that are not STANDARD-OBJECTs. Normally, the default
methods provided by classes FUNDAMENTAL-INPUT-STREAM and
FUNDAMENTAL-OUTPUT-STREAM are sufficient. Note that, for example,
(INPUT-STREAM-P x) is not equivalent to (TYPEP x
'FUNDAMENTAL-INPUT-STREAM) because implementations may have
additional ways of defining their own streams even if they don't
make that visible by making these predicates generic.
STREAM-ELEMENT-TYPE stream [Generic Function]
This existing function is made generic, but otherwise behaves the
same. Class FUNDAMENTAL-CHARACTER-STREAM provides a default method
which returns CHARACTER.
PATHNAME and TRUENAME are also permitted to be implemented as generic
functions. There is no default method since these are not valid for
all streams.
Binary streams:
Binary streams can be created by defining a class that includes either
FUNDAMENTAL-BINARY-INPUT-STREAM or FUNDAMENTAL-BINARY-OUTPUT-STREAM
(or both) and defining a method for STREAM-ELEMENT-TYPE and for one or
both of the following generic functions.
STREAM-READ-BYTE stream [Generic Function]
Used by READ-BYTE; returns either an integer, or the symbol :EOF if the
stream is at end-of-file.
STREAM-WRITE-BYTE stream integer [Generic Function]
Implements WRITE-BYTE; writes the integer to the stream and returns
the integer as the result.
Rationale:
The existing I/O functions cannot be made generic because, in nearly
every case, the stream argument is optional, and therefore cannot be
specialized. Therefore, it is necessary to define a lower-level
generic function to be used by the existing function. It also isn't
appropriate to specialize on the second argument of PRINT-OBJECT because
it is a higher-level function -- even when the first argument is a
character or a string, it needs to format it in accordance with
*PRINT-ESCAPE*.
In order to make the meaning as obvious as possible, the names of the
generic functions have been formed by prefixing "STREAM-" to the
corresponding non-generic function.
Having the generic input functions just return :EOF at end-of-file, with
the higher-level functions handling the eof-error-p and eof-value
arguments, simplifies the generic function interface and makes it more
efficient by not needing to pass through those arguments. Note that the
functions that use this convention can only return a character or
integer as a stream element, so there is no possibility of ambiguity.
Functions STREAM-LINE-COLUMN, STREAM-START-LINE-P, and
STREAM-ADVANCE-TO-COLUMN may appear to be a reincarnation of the
defeated proposal STREAM-INFO, but the motivation here is different.
This interface needs to be defined if user-defined streams are to be
able to be used by PPRINT and FORMAT ~T, which could be viewed as a
separate question from whether the user can call then on
system-defined streams.
Current practice:
No one currently supports exactly this proposal, but this is very
similar to the stream interface used in CLUE.
On descendants of the MIT Lisp Machine, streams can be implemented
by users as either flavors, with methods to accept the various
messages corresponding to the I/O operations, or as functions, which
take a message keyword as their first argument.
Examples:
;;;; Here is an example of how the default methods could be
;;;; implemented (omitting the most trivial ones):
(defmethod STREAM-PEEK-CHAR ((stream fundamental-character-input-stream))
(let ((character (stream-read-char stream)))
(unless (eq character :eof)
(stream-unread-char stream character))
character))
(defmethod STREAM-LISTEN ((stream fundamental-character-input-stream))
(let ((char (stream-read-char-no-hang stream)))
(and (not (null char))
(not (eq char :eof))
(progn (stream-unread-char stream char) t))))
(defmethod STREAM-READ-LINE ((stream fundamental-character-input-stream))
(let ((line (make-array 64 :element-type 'string-char
:fill-pointer 0 :adjustable t)))
(loop (let ((character (stream-read-char stream)))
(if (eq character :eof)
(return (values line t))
(if (eql character #\newline)
(return (values line nil))
(vector-push-extend character line)))))))
(defmethod STREAM-START-LINE-P ((stream fundamental-character-output-stream))
(equal (stream-line-column stream) 0))
(defmethod STREAM-WRITE-STRING ((stream fundamental-character-output-stream)
string &optional (start 0)
(end (length string)))
(do ((i start (1+ i)))
((>= i end) string)
(stream-write-char stream (char string i))))
(defmethod STREAM-TERPRI ((stream fundamental-character-output-stream))
(stream-write-char stream #\newline)
nil)
(defmethod STREAM-FRESH-LINE ((stream fundamental-character-output-stream))
(if (stream-start-line-p stream)
nil
(progn (stream-terpri stream) t)))
(defmethod STREAM-ADVANCE-TO-COLUMN ((stream fundamental-character-output-stream)
column)
(let ((current (stream-line-column stream)))
(unless (null current)
(dotimes (i (- current column) t)
(stream-write-char stream #\space)))))
(defmethod INPUT-STREAM-P ((stream fundamental-input-stream)) t)
(defmethod INPUT-STREAM-P ((stream fundamental-output-stream))
;; allow the two classes to be mixed in either order
(typep stream 'fundamental-input-stream))
(defmethod OUTPUT-STREAM-P ((stream fundamental-output-stream)) t)
(defmethod OUTPUT-STREAM-P ((stream fundamental-input-stream))
(typep stream 'fundamental-output-stream))
;;;; Following is an example of how the existing I/O functions could
;;;; be implemented using standard Common Lisp and the generic
;;;; functions specified above. The standard functions being defined
;;;; are in upper case.
;; Internal helper functions
(proclaim '(inline decode-read-arg decode-print-arg check-for-eof))
(defun decode-read-arg (arg)
(cond ((null arg) *standard-input*)
((eq arg t) *terminal-io*)
(t arg)))
(defun decode-print-arg (arg)
(cond ((null arg) *standard-output*)
((eq arg t) *terminal-io*)
(t arg)))
(defun check-for-eof (value stream eof-errorp eof-value)
(if (eq value :eof)
(report-eof stream eof-errorp eof-value)
value))
(defun report-eof (stream eof-errorp eof-value)
(if eof-errorp
(error 'end-of-file :stream stream)
eof-value))
;;; Common Lisp input functions
(defun READ-CHAR (&optional input-stream (eof-errorp t) eof-value recursive-p)
(declare (ignore recursive-p)) ; a mistake in CLtL?
(let ((stream (decode-read-arg input-stream)))
(check-for-eof (stream-read-char stream) stream eof-errorp eof-value)))
(defun PEEK-CHAR (&optional peek-type input-stream (eof-errorp t)
eof-value recursive-p)
(declare (ignore recursive-p))
(let ((stream (decode-read-arg input-stream)))
(if (null peek-type)
(check-for-eof (stream-peek-char stream) stream eof-errorp eof-value)
(loop
(let ((value (stream-peek-char stream)))
(if (eq value :eof)
(return (report-eof stream eof-errorp eof-value))
(if (if (eq peek-type t)
(not (member value '(#\space #\tab #\newline
#\page #\return #\linefeed)))
(char= peek-type value))
(return value)
(stream-read-char stream))))))))
(defun UNREAD-CHAR (character &optional input-stream)
(stream-unread-char (decode-read-arg input-stream) character))
(defun LISTEN (&optional input-stream)
(stream-listen (decode-read-arg input-stream)))
(defun READ-LINE (&optional input-stream (eof-error-p t)
eof-value recursive-p)
(declare (ignore recursive-p))
(let ((stream (decode-read-arg input-stream)))
(multiple-value-bind (string eofp)
(stream-read-line stream)
(if eofp
(if (= (length string) 0)
(report-eof stream eof-error-p eof-value)
(values string t))
(values string nil)))))
(defun CLEAR-INPUT (&optional input-stream)
(stream-clear-input (decode-read-arg input-stream)))
(defun READ-CHAR-NO-HANG (&optional input-stream (eof-errorp t)
eof-value recursive-p)
(declare (ignore recursive-p))
(let ((stream (decode-read-arg input-stream)))
(check-for-eof (stream-read-char-no-hang stream)
stream eof-errorp eof-value)))
;;; Common Lisp output functions
(defun WRITE-CHAR (character &optional output-stream)
(stream-write-char (decode-print-arg output-stream) character))
(defun FRESH-LINE (&optional output-stream)
(stream-fresh-line (decode-print-arg output-stream)))
(defun TERPRI (&optional output-stream)
(stream-terpri (decode-print-arg output-stream)))
(defun WRITE-STRING (string &optional output-stream &key (start 0) end)
(stream-write-string (decode-print-arg output-stream) string start end))
(defun WRITE-LINE (string &optional output-stream &key (start 0) end)
(let ((stream (decode-print-arg output-stream)))
(stream-write-string stream string start end)
(stream-terpri stream)
string))
(defun FORCE-OUTPUT (&optional stream)
(stream-force-output (decode-print-arg stream)))
(defun FINISH-OUTPUT (&optional stream)
(stream-finish-output (decode-print-arg stream)))
(defun CLEAR-OUTPUT (&optional stream)
(stream-clear-output (decode-print-arg stream)))
;;; Binary streams
(defun READ-BYTE (binary-input-stream &optional (eof-errorp t) eof-value)
(check-for-eof (stream-read-byte binary-input-stream)
binary-input-stream eof-errorp eof-value))
(defun WRITE-BYTE (integer binary-output-stream)
(stream-write-byte binary-output-stream integer))
;;; String streams
(defclass string-input-stream (fundamental-character-input-stream)
((string :initarg :string :type string)
(index :initarg :start :type fixnum)
(end :initarg :end :type fixnum)
))
(defun MAKE-STRING-INPUT-STREAM (string &optional (start 0) end)
(make-instance 'string-input-stream :string string
:start start :end (or end (length string))))
(defmethod stream-read-char ((stream string-input-stream))
(with-slots (index end string) stream
(if (>= index end)
:eof
(prog1 (char string index)
(incf index)))))
(defmethod stream-unread-char ((stream string-input-stream) character)
(with-slots (index end string) stream
(decf index)
(assert (eql (char string index) character))
nil))
(defmethod stream-read-line ((stream string-input-stream))
(with-slots (index end string) stream
(let* ((endline (position #\newline string :start index :end end))
(line (subseq string index endline)))
(if endline
(progn (setq index (1+ endline))
(values line nil))
(progn (setq index end)
(values line t))))))
(defclass string-output-stream (fundamental-character-output-stream)
((string :initform nil :initarg :string)))
(defun MAKE-STRING-OUTPUT-STREAM ()
(make-instance 'string-output-stream))
(defun GET-OUTPUT-STREAM-STRING (stream)
(with-slots (string) stream
(if (null string)
""
(prog1 string (setq string nil)))))
(defmethod stream-write-char ((stream string-output-stream) character)
(with-slots (string) stream
(when (null string)
(setq string (make-array 64. :element-type 'string-char
:fill-pointer 0 :adjustable t)))
(vector-push-extend character string)
character))
(defmethod stream-line-column ((stream string-output-stream))
(with-slots (string) stream
(if (null string)
0
(let ((nx (position #\newline string :from-end t)))
(if (null nx)
(length string)
(- (length string) nx 1))
))))
Cost to Implementors:
Given that CLOS is supported, adding the above generic functions and
methods is easy, since most of the code is included in the examples
above. The hard part would be re-writing existing I/O functionality in
terms of methods on these new generic functions. That could be
simplified if methods can be defined to forward the operations to the
old representation of streams. For a new implementation, the cost could
be zero since an approach similar to this would likely be used anyway.
Cost to Users:
None; this is an upward-compatible addition. Users won't even
need to know anything about this unless they actually need this feature.
Cost of non-adoption:
Development of portable I/O extensions will be discouraged.
Performance impact:
This shouldn't affect performance of new implementations (assuming an
efficient CLOS implementation), but it could slow down I/O if it were
clumsily grafted on top of an existing implementation.
Benefits:
A broader domain of programs that can be written portably.
Esthetics:
This seems to be a simple, straight-forward approach.
Discussion:
This proposal incorporates suggestions made by several people in
response to an earlier outline. So far, no one has expressed opposition
to the concept. There are some differences of opinion about whether
certain operations should have default methods or required methods:
STREAM-LISTEN, STREAM-READ-CHAR-NO-HANG, STREAM-LINE-COLUMN,
and STREAM-START-LINE-P.
An experimental prototype of this has been successfully implemented on
the Explorer.
This proposal does not provide sufficient capability to implement
forwarding streams such as for MAKE-SYNONYM-STREAM,
MAKE-BROADCAST-STREAM, MAKE-CONCATENATED-STREAM, MAKE-TWO-WAY-STREAM, or
MAKE-ECHO-STREAM. The generic function approach does not lend itself as
well to that as a message passing model where the intermediary does not
need to know what all the possible messages are. A possible way of
extending it for that would be to define a class
(defclass stream-generic-function (standard-generic-function) ())
to be used as the :generic-function-class option for all of the I/O
generic functions. This would then permit doing something like
(defmethod no-applicable-method ((gfun stream-generic-function) &rest args)
(if (streamp (first args))
(apply #'stream-operation-not-handled (first args) gfun (rest args))
(call-next-method)))
where stream-operation-not-handled is a generic function whose default
method signals an error, but forwarding streams can define methods that
will create a method to handle the unexpected operation. (Perhaps
NO-APPLICABLE-METHOD should be changed to take two required arguments
since all generic functions need at least one required argument, and
that would make it unnecessary to define a new generic function class
just to be able to write this one method.)
Another thing that is not addressed here is a way to cause an instance
of a user-defined stream class to be created from a call to the OPEN
function. That should be part of a separate issue for generic functions
on pathnames. If that capability were available, then PATHNAME and
TRUENAME should be required to be generic functions.
An earlier draft defined just two classes, FUNDAMENTAL-INPUT-STREAM and
FUNDAMENTAL-OUTPUT-STREAM, that were used for both character and binary
streams. It isn't clear whether that simple approach is sufficient or
whether the larger set of classes is really needed.
∂23-Mar-89 1813 CL-Cleanup-mailer Re: Issue: READ-CASE-SENSITIVITY (Version 2)
Received: from Sun.COM by SAIL.Stanford.EDU with TCP; 23 Mar 89 18:13:26 PST
Received: from snail.Sun.COM (snail.Corp.Sun.COM) by Sun.COM (4.1/SMI-4.0)
id AA08865; Thu, 23 Mar 89 18:15:31 PST
Received: from denali.sun.com by snail.Sun.COM (4.1/SMI-4.1)
id AA14491; Thu, 23 Mar 89 18:11:37 PST
Received: from localhost by denali.sun.com (3.2/SMI-3.2)
id AA04765; Thu, 23 Mar 89 18:14:55 PST
Message-Id: <8903240214.AA04765@denali.sun.com>
To: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Cc: jeff%aiai.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK
Cc: CL-Cleanup@sail.stanford.edu
Subject: Re: Issue: READ-CASE-SENSITIVITY (Version 2)
In-Reply-To: Your message of Thu, 23 Mar 89 18:56:00 -0500;
<890323185605.7.KMP@BOBOLINK.SCRC.Symbolics.COM> .
Date: Thu, 23 Mar 89 18:14:53 PST
From: peck@Sun.COM
>(2) the lack of need to add CHAR-INVERT-CASE (which I don't think is very
> useful outside of this context).
I guess i don't see how this is useful even in this context.
Is this a Symbolics'ism?
If :preserve is an option, why would someone want :INVERT?
dOES SOMEONE THINK :invert IS EASIER TO TYPE THAN eSCAPES or vERTICAL-bARS?
dO YOU HAVE files WRITTEN WITH :invert?
How about throwing out :INVERT *and* CHAR-INVERT-CASE?
Which of READTABLE-KEYWORDS or READTABLE-FUNCTIONS would you prefer then?
[given a sufficiently powerful Emacs that can escape the chars before
passing them to the Lisp reader, does any of this matter to X3J13?]
While we are busy trying to be KSR33 compatible, the rest of the world
may zoom on by. The Japanese won't be interested in much of this code.
Oops, sorry, that is not a cleanup issue.
∂23-Mar-89 1518 CL-Cleanup-mailer Issue: DIRECTORY-DOES-TOO-MUCH
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 23 Mar 89 15:13:59 PST
Received: from pitney-bowes ([192.9.200.50]) by heavens-gate.lucid.com id AA03822g; Thu, 23 Mar 89 15:08:24 PST
Received: by pitney-bowes id AA26773g; Thu, 23 Mar 89 15:06:47 PST
Date: Thu, 23 Mar 89 15:06:47 PST
From: Jim McDonald <jlm@lucid.com>
Message-Id: <8903232306.AA26773@pitney-bowes>
To: CL-Cleanup@SAIL.Stanford.edu
Subject: Issue: DIRECTORY-DOES-TOO-MUCH
While thinking about pathnames, I was reminded of this possible small
addition:
Issue: DIRECTORY-DOES-TOO-MUCH
Forum: Cleanup
References: DIRECTORY (p427)
Related issues: NONE
Category: ADDITION
Edit history: 14-Mar-89, Version 1 by James L. McDonald
Status: For Internal Discussion
Problem description:
According to CLtL, DIRECTORY returns a list of truenames, "one for
each file in the file system that matches the given pathname".
The problem is that sometimes one wants the truenames for just one
or a few of the files that match, or one wants to interleave
processing of each file as it is found, to minimize the start-up
time when processing large directories.
Proposal (DIRECTORY-DOES-TOO-MUCH:ADD-GENERATOR):
Add the function DIRECTORY-GENERATOR which would accept the same
argument spectrum as DIRECTORY and return a function which, when
successively applied, would yield each of truenames in the list
of truenames that DIRECTORY would have returned, and then NIL to
indicate no more files are available.
Examples:
This example illustrates how wasted effort could be avoided:
(DEFUN FIND-DEFINING-FILE (MUMBLE)
(LET ((FN (DIRECTORY-GENERATOR "/moby-dir/*.lisp")))
(DO ((TRUENAME (FUNCALL FN) (FUNCALL FN)))
((NULL TRUENAME)
NIL)
(WHEN (FILE-DEFINES-P TRUENAME MUMBLE)
(RETURN TRUENAME)))))
This example shows how a system with some distributed processing
ability might interleave file accessing and processing:
(DEFUN COMPILE-WORLD ()
(LET ((FN (DIRECTORY-GENERATOR "/moby-dir/*.lisp")))
(DO ((TRUENAME (FUNCALL FN) (FUNCALL FN)))
((NULL TRUENAME)
NIL)
(INITIATE-DISTRIBUTED-COMPILATION TRUENAME))))
Test Cases:
This should return true for all arguments, assuming that during
the execution of the test files are not added to or removed from
the file-system being accessed.
(DEFUN FOO (X)
(OR (NOT (PATHNAMEP X))
(NULL (SET-EXCLUSIVE-OR ; why doesn't CL have SET-EQUAL ?
(DIRECTORY X)
(LET ((FN (DIRECTORY-GENERATOR X))
(DIR '()))
(DO ((TRUENAME (FUNCALL FN) (FUNCALL FN)))
((NULL TRUENAME)
(REVERSE DIR))
(PUSH TRUENAME DIR)))))))
Rationale:
This seems simple, useful, and uncontroversial. For many file
systems, it provides a CL primitive that maps more directly to
underlying OS primitives.
Current practice:
Lucid Common Lisp has always implemented DIRECTORY in much this way.
Cost to Implementors:
Minimal. Any port could come into compliance by defining
DIRECTORY-GENERATOR as:
(DEFUN DIRECTORY-GENERATOR (X)
(LET ((DIR (DIRECTORY X)))
#'(LAMBDA () (POP DIR))))
Implementing it more directly is probably either a fairly small task
or clearly impossible. Either way, not much work.
Cost to Users:
None.
Cost of non-adoption:
DIRECTORY continues to be needlessly inefficient in some cases.
Performance impact:
Some programs may run faster or reduce the maximum delay visible
to users.
Benefits:
See performance impact.
Esthetics:
Minor.
Discussion:
The test case presumes truenames are generated in the same order
that DIRECTORY now lists them. This is a minor restriction but
would fail for systems that explicitly sort their results or file
systems that randomly reorder directories (e.g. on every access).
Set equivalence is probably just as good a test if anyone cares.
∂23-Mar-89 1534 CL-Cleanup-mailer Re: Issue: GENSYM-NAME-STICKINESS (Version 3)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 23 Mar 89 15:32:17 PST
Received: from Semillon.ms by ArpaGateway.ms ; 23 MAR 89 12:59:59 PST
Date: 23 Mar 89 12:59 PST
From: masinter.pa@Xerox.COM
Subject: Re: Issue: GENSYM-NAME-STICKINESS (Version 3)
In-reply-to: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>'s message
of Tue, 21 Mar 89 11:45 EST
To: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
cc: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <890323-125959-5425@Xerox>
please release to X3J13; thanks.
∂23-Mar-89 2050 CL-Cleanup-mailer Re: Issue: READ-CASE-SENSITIVITY (Version 2)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 23 Mar 89 20:50:36 PST
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 564301; Thu 23-Mar-89 23:49:43 EST
Date: Thu, 23 Mar 89 23:49 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: Issue: READ-CASE-SENSITIVITY (Version 2)
To: peck@Sun.COM
cc: KMP@STONY-BROOK.SCRC.Symbolics.COM,
jeff%aiai.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK,
CL-Cleanup@sail.stanford.edu
In-Reply-To: <8903240214.AA04765@denali.sun.com>
Message-ID: <890323234914.8.KMP@BOBOLINK.SCRC.Symbolics.COM>
I shouldn't even be bothering to reply to a message like this at this late
date. I have better things to be doing. However, I'll let this be my one
for the day -- if only to lend a little support to Jeff because I think
the tone of ridicule in your message to be somewhat out of line. In spite
of this, I've tried to keep my tone constructive and to answer your questions
in earnest.
Date: Thu, 23 Mar 89 18:14:53 PST
From: peck@Sun.COM
>(2) the lack of need to add CHAR-INVERT-CASE (which I don't think is very
> useful outside of this context).
I guess i don't see how this is useful even in this context.
Is this a Symbolics'ism?
I didn't find this remark to be particularly professional. I wish we could
just avoid that kind of thing.
The answer happens to be "no", it is not something we use here.
It's something Jeff dreamed up, I guess.
I didn't oppose it because I'm not in the habit of out-of-hand opposing
things just because I personally don't see as having practical value. I
think the real acid test of willingness to cooperate on compatibility is
a willingness to tolerate noops and useless features because they turn
out to be useful to someone else.
My offhand guess is that it is in fact useful in some implementations.
Your example below which uses mixed case doesn't give it fair play.
Suppose there's an intermediate situation where you implement an embedded
language in which you can only use all-uppercase or all-lowercase names.
Suppose you want the all-lowercase names to be the ones that correspond to
Lisp names. I don't happen to want to do that, but it seemed plausible to
me that someone might -- and it might be what Jeff had in mind.
The cost of the feature he's asking for is very small, especially if you
consider the hair someone would have to go through to write that embedded
language portably if you didn't offer the feature.
If :preserve is an option, why would someone want :INVERT?
dOES SOMEONE THINK :invert IS EASIER TO TYPE THAN eSCAPES or vERTICAL-bARS?
dO YOU HAVE files WRITTEN WITH :invert?
How about throwing out :INVERT *and* CHAR-INVERT-CASE?
How about being civil and first asking Jeff politely why he wanted the feature.
Which of READTABLE-KEYWORDS or READTABLE-FUNCTIONS would you prefer then?
It doesn't affect my vote. I still prefer the former over the latter, and I
still don't seriously oppose the latter.
[given a sufficiently powerful Emacs that can escape the chars before
passing them to the Lisp reader, does any of this matter to X3J13?]
The issue is not text editors. Given a sufficiently powerful Emacs, you could
code in C and still pass your information off to Lisp. ``It's only software''
as they say. The issue is that the language must be defined as the interface
between the outside world and Lisp. The language is exactly what you can expect
to be held constant as you move from system to system, text editor to text editor.
Either the language handles case conversion or the text editor does.
Jeff is suggesting that he would like the text editor to do so. I don't happen
to want to do that, but I can't deny that he is making a fair request.
While we are busy trying to be KSR33 compatible, the rest of the world
may zoom on by.
I have never used a KSR33. I think I've seen one. I have no particular desire
to be compatible with one. I can't imagine why this remark is relevant here.
The Japanese won't be interested in much of this code.
Oops, sorry, that is not a cleanup issue.
In my mind, it is not our purpose to design a language suitable for the Japanese.
It is our purpose to design a language suitable for us, and to try to listen
to the Japanese (and anyone else) about problems what we do might cause. While
this feature might not be interesting to them, it's hard to see how it could
cause them any problem.
The Japanese will have their opportunity to speak, and I will pay close attention.
If you say what you personally want and why, sans ridicule, I will try to pay
close attention to that, too.
∂23-Mar-89 2232 CL-Cleanup-mailer Issue: DIRECTORY-DOES-TOO-MUCH
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 23 Mar 89 22:32:44 PST
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 564358; Fri 24-Mar-89 01:32:03 EST
Date: Fri, 24 Mar 89 01:31 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: DIRECTORY-DOES-TOO-MUCH
To: jlm@lucid.com
cc: CL-Cleanup@SAIL.Stanford.EDU
In-Reply-To: <8903232306.AA26773@pitney-bowes>
Message-ID: <890324013136.9.KMP@BOBOLINK.SCRC.Symbolics.COM>
I don't oppose your proposal, but I have some non-preemptive remarks
that you might want to consider factoring into a revision if you have
time to pursue the issue. (I really don't know how much I believe these
suggestions, but they occurred to me and I thought I would share them.)
Criticisms:
- I think the name DIRECTORY-GENERATOR is a bit long
and not startlingly perspicuous.
- I think that returning a function means that some common
cases will seem unduly complicated because of the need to
FUNCALL the result to turn it into a useable form.
These are not fatal flaws, but they drive the following suggestions:
You might want an interface like
(DIRECTORY-1 pathname) => pathname-or-nil, function-or-nil
[Actually, it's clear that first return value has to be NIL.
The second return value doesn't have to be NIL -- it could be
a function which returns NIL when called, but people might want
to optimize that case.]
The name is by analogy with MACROEXPAND-1. You'd get a useful
primary value and some more-p information in the secondary value
that you could discard if you didn't want.
The really nice feature of the data flow is, of course, that you can
directly use the single return value without further fuss or funcall.
You might even want to allow it to taken an optional argument saying
you didn't want the second return value (i.e., that NIL was ok) to
avoid consing.
(DIRECTORY-1 pathname NIL) => pathname-or-nil, nil
Alternatively, or additionally, you might want to think about
extending DIRECTORY to take a keyword requesting the indicated
functionality. e.g.,
(DIRECTORY pathname :COUNT 1)
might want to return just the first pathname, presumably as a list
to be compatible with the normal style of DIRECTORY, and to generalize
nicely to :COUNT arguments like 0 or 2.
If this were an alternative to DIRECTORY-1, it could also return a
second return value which was the stepper function (or NIL if none).
If this were just in addition to DIRECTORY-1, then it could arguably
not bother with the second return value and make you call DIRECTORY-1
if you needed that much power.
∂24-Mar-89 0745 CL-Cleanup-mailer Re: Issue: DIRECTORY-DOES-TOO-MUCH
Received: from RELAY.CS.NET by SAIL.Stanford.EDU with TCP; 24 Mar 89 07:44:59 PST
Received: from relay2.cs.net by RELAY.CS.NET id aa08010; 24 Mar 89 10:29 EST
Received: from draper.com by RELAY.CS.NET id aa00637; 24 Mar 89 10:25 EST
Date: Fri, 24 Mar 89 09:17 EST
From: "Steve Bacher (Batchman)" <SEB1525@draper.com>
Subject: Re: Issue: DIRECTORY-DOES-TOO-MUCH
To: cl-cleanup@SAIL.STANFORD.EDU
X-VMS-To: CL-CLEANUP,SEB1525
> Date: Fri, 24 Mar 89 01:31 EST
> From: Kent M Pitman <KMP@stony-brook.scrc.symbolics.COM>
> Subject: Issue: DIRECTORY-DOES-TOO-MUCH
> To: jlm@lucid.COM
>
> You might want an interface like
>
> (DIRECTORY-1 pathname) => pathname-or-nil, function-or-nil
>
> [Actually, it's clear that first return value has to be NIL.
> The second return value doesn't have to be NIL -- it could be
> a function which returns NIL when called, but people might want
> to optimize that case.]
>
[...]
>
> You might even want to allow it to taken an optional argument saying
> you didn't want the second return value (i.e., that NIL was ok) to
> avoid consing.
>
> (DIRECTORY-1 pathname NIL) => pathname-or-nil, nil
Now that's a slippery slope. If we start allowing functions to take an
optional argument telling them how many values {not} to return, where do
we stop? In any case, it's the job of the compiler and its many optimizers,
in most cases, to determine when and if it is possible/feasible/desirable to
generate code that avoids returning unused values.
Plus, which is more painful - a few extra conses, or the directory lookup
in the first place? (Answer: implementation-dependent.)
∂24-Mar-89 0807 CL-Cleanup-mailer Meeting 1 hour before plenary session?
Received: from Riverside.SCRC.Symbolics.COM (SCRC-RIVERSIDE.ARPA) by SAIL.Stanford.EDU with TCP; 24 Mar 89 08:07:41 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by Riverside.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 325694; Fri 24-Mar-89 11:06:59 EST
Date: Fri, 24 Mar 89 11:07 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Meeting 1 hour before plenary session?
To: masinter.pa@XEROX.COM
cc: cl-cleanup@SAIL.STANFORD.EDU
In-Reply-To: <890323-122134-5313@Xerox>
Message-ID: <19890324160717.5.MOON@EUPHRATES.SCRC.Symbolics.COM>
Line-fold: No
Date: 23 Mar 89 12:19 PST
From: masinter.pa@Xerox.COM
I'm back near a mailbox. Can we get together an hour before the main
session to go over the cleanup report agenda? I want to order the cleanup
issues so that we handle the "important" ones first. I roughly think that
means:
a) fix the cleanups that were previously broken
b) clarifications
c) changes
c) additions
within each category, order mainly by age: handle oldest issues first. But
then, there are some of these that are more 'important' that we'll want to
mess up the order.
This sounds good. Also we may want to move related issues next to each
other (although the pathname issues will be next to each other in alphabetical
order).
I plan to put together a proposal for dealing with these over the next few
days and will mail it out, but you might want to come prepared with your
own list of "things that are critically important to get voted on this
meeting".
It's too late to mail any more things out, at least for me. I hope not to
work this weekend.
∂24-Mar-89 1015 CL-Cleanup-mailer Re: Issue: READ-CASE-SENSITIVITY (Version 2)
Received: from NSS.Cs.Ucl.AC.UK by SAIL.Stanford.EDU with TCP; 24 Mar 89 10:14:11 PST
Received: from aiai.edinburgh.ac.uk by NSS.Cs.Ucl.AC.UK via Janet with NIFTP
id aa03563; 24 Mar 89 16:30 GMT
Date: Fri, 24 Mar 89 16:32:37 GMT
Message-Id: <3273.8903241632@subnode.aiai.ed.ac.uk>
From: Jeff Dalton <jeff%aiai.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK>
Subject: Re: Issue: READ-CASE-SENSITIVITY (Version 2)
To: Kent M Pitman <KMP@scrc-stony-brook.arpa>, peck@sun.com
Cc: CL-Cleanup@sail.stanford.edu
> How about throwing out :INVERT *and* CHAR-INVERT-CASE?
> Which of READTABLE-KEYWORDS or READTABLE-FUNCTIONS would you prefer then?
Probably FUNCTIONS. But then for a random function (e.g., a
CHAR-INVERT-CASE defined by me), I'd want output to leave case
intact, without escapes.
-- Jeff
∂24-Mar-89 1024 CL-Cleanup-mailer Re: Issue: READ-CASE-SENSITIVITY (Version 2)
Received: from NSS.Cs.Ucl.AC.UK by SAIL.Stanford.EDU with TCP; 24 Mar 89 10:24:32 PST
Received: from aiai.edinburgh.ac.uk by NSS.Cs.Ucl.AC.UK via Janet with NIFTP
id aa03359; 24 Mar 89 15:59 GMT
Date: Fri, 24 Mar 89 16:01:12 GMT
Message-Id: <2935.8903241601@subnode.aiai.ed.ac.uk>
From: Jeff Dalton <jeff%aiai.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK>
Subject: Re: Issue: READ-CASE-SENSITIVITY (Version 2)
To: Kent M Pitman <KMP@scrc-stony-brook.arpa>, peck@sun.com
Cc: CL-Cleanup@sail.stanford.edu
I do not understand why this proposal causes such confusion. Perhaps
my writing isn't as clear as it might be, but I don't think it's that
bad.
> >(2) the lack of need to add CHAR-INVERT-CASE (which I don't think is very
> > useful outside of this context).
> I guess i don't see how this is useful even in this context.
> Is this a Symbolics'ism?
No.
> If :preserve is an option, why would someone want :INVERT?
It's in the rationale. If I set the readtable to :PRESERVE and
then want to use it to keep case distinctions in my Lisp code --
some people do want to do this -- I may also want to type the names
of symbols in the "LISP" package in lower case rather than upper.
There are two ways to get that: change the internal case to lower
or invert what's typed in.
> dOES SOMEONE THINK :invert IS EASIER TO TYPE THAN eSCAPES or vERTICAL-bARS?
> dO YOU HAVE files WRITTEN WITH :invert?
No, someone thinks (car x) is nicer than (CAR x).
One may well have files written in :INVERT. Any file that uses only
lower case for Lisp code relies on case-insensitivity to convert the
names to upper case. Those same files could just as well be read
with :INVERT.
> [given a sufficiently powerful Emacs that can escape the chars before
> passing them to the Lisp reader, does any of this matter to X3J13?]
Given sufficiently powerful tools other than Lisp, why does anything
matter to X3J13?
Besides, is Emacs going to read all of my streams for me?
> While we are busy trying to be KSR33 compatible, the rest of the world
> may zoom on by. The Japanese won't be interested in much of this code.
> Oops, sorry, that is not a cleanup issue.
The only thing in any of this that's could reasonably be called KSR33
compatible is the choice of upper case for the internal preferred
case. This proposal is trying to make that choice less significant.
-- Jeff
∂24-Mar-89 1344 CL-Cleanup-mailer Re: Issue: READ-CASE-SENSITIVITY (Version 2)
Received: from Sun.COM by SAIL.Stanford.EDU with TCP; 24 Mar 89 13:44:38 PST
Received: from snail.Sun.COM (snail.Corp.Sun.COM) by Sun.COM (4.1/SMI-4.0)
id AA00368; Fri, 24 Mar 89 13:46:08 PST
Received: from denali.sun.com by snail.Sun.COM (4.1/SMI-4.1)
id AA19874; Fri, 24 Mar 89 13:42:14 PST
Received: from localhost by denali.sun.com (3.2/SMI-3.2)
id AA07858; Fri, 24 Mar 89 13:45:29 PST
Message-Id: <8903242145.AA07858@denali.sun.com>
To: Jeff Dalton <jeff%aiai.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK>
Cc: CL-Cleanup@sail.stanford.edu
Subject: Re: Issue: READ-CASE-SENSITIVITY (Version 2)
In-Reply-To: Your message of Fri, 24 Mar 89 16:01:12 +0000;
<2935.8903241601@subnode.aiai.ed.ac.uk> .
Date: Fri, 24 Mar 89 13:45:27 PST
From: peck@Sun.COM
Assuming that my confusion about :invert is resolved offline,
I have another, more positive suggestion for getting CommonLisp
into the case-sensitive world:
The biggest block that i've found to writting portable code
in the mixed/preserve case world is those times when you want
intern a symbol from a string. If the string is either hard-coded
(as a prefix string or :conc-name) or as entered from a user with
a readline equivalent, then the application should have a means
of converting the string as the reader would. I have found use
for the function (CASE-CONVERT-NAME <string>) which returns a
string which would be the name of a symbol if <string> were read
by the reader.
;;; This definition returns mostly the correct value,
;;; but has numerous unwanted side-effects,
;;; I.E. creates and interns a symbol, chokes on by colons, etc.
(defun CASE-CONVERT-NAME (string)
(symbol-name (read-from-string string)))
;;; this is much closer, with READTABLE-CASE-SENSITIVITY:READTABLE-KEYWORDS
(defun CASE-CONVERT-NAME (string)
(case (readtable-case-sensitivity *readtable*)
(:preserve string)
(:upcase (string-upcase string))
(:downcase (string-downcase string))
(:invert (string-invertcase string)) ;; uses char-invert-case?
))
;;; or this, with READTABLE-CASE-SENSITIVITY:READTABLE-FUNCTIONS
(defun CASE-CONVERT-NAME (string)
(map 'string (readtable-case-sensitivity *readtable*) string))
If we could have a function such as this in the, maybe folks
would use it: (intern (concatentate 'string
(case-convert-name "foo-")
(case-convert-name sym) )
pkg)
Instead of: (intern (concatentate 'string "FOO-" sym) pkg)
With this extra layer, writing protable code to case-sensitive lisp
is very much easier. The version i use even has an extra arguement
to control whether destructive (in-place) or copying conversion is done.
∂25-Mar-89 1209 CL-Cleanup-mailer Cleanup Meeting
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 25 Mar 89 12:09:47 PST
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 565298; Sat 25-Mar-89 15:09:31 EST
Date: Sat, 25 Mar 89 15:09 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Cleanup Meeting
To: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <890325150902.2.KMP@BOBOLINK.SCRC.Symbolics.COM>
Larry asked me to send mail clarifying that the Cleanup meeting will
be Tuesday morning at 8am at Contel, with full X3J13 to meet at 9am.
Probably all we'll have time to do at the early Cleanup meeting is
discuss strategy/priority for presentation--not discuss individual
issues.
∂29-Mar-89 1535 CL-Cleanup-mailer new version of LOAD-TRUENAME
Received: from ctc.contel.com (goofy.ctc.contel.com) by SAIL.Stanford.EDU with TCP; 29 Mar 89 15:35:10 PST
Received: from mickey.ctc.contel.com by ctc.contel.com (4.0/870914.1{Enger})
id AA11354; Wed, 29 Mar 89 18:35:27 EST
Received: by mickey.ctc.contel.com (4.0/SMI-4.0)
id AA01906; Wed, 29 Mar 89 18:36:33 EST
Date: Wed, 29 Mar 89 18:36:33 EST
From: mathis@mickey.ctc.contel.com (Bob Mathis)
Message-Id: <8903292336.AA01906@mickey.ctc.contel.com>
To: mathis@mickey.ctc.contel.com
Subject: new version of LOAD-TRUENAME
Cc: cl-cleanup@sail.stanford.edu
(composed by Moon w/editing by Masinter in Mathis office)
Issue: LOAD-TRUENAME
Forum: Cleanup
References: LOAD (p426), PROVIDE (p188), REQUIRE (p188),
Issue REQUIRE-PATHNAME-DEFAULTS
Category: ADDITION
Edit history: 13-Mar-89, Version 1 by Pitman
29-Mar-89, Version 2 by Moon (add -PATHNAME vars)
Problem Description:
It is difficult to construct sets of software modules which work
together as a unit and which port between different implementations.
REQUIRE and PROVIDE were intended to provide this level of support
but have `failed' to be portable in practice.
Typical user configurations involve a `system definition' file which
loads the modules of a `system' (collection of software modules).
Among the specific problems which arise are:
- File system types may vary. Different file syntax must be used for
each site.
- Even with the same Lisp implementation and host file system type,
the directory in which a software system resides may differ from
delivery site to delivery site.
- Multiple `copies' of the same system may reside in different
directories on the same machine.
Proposal (LOAD-TRUENAME:NEW-PATHNAME-VARIABLES):
Introduce new variables:
*LOAD-TRUENAME* [Variable]
This special variable is initially NIL, but is bound by LOAD to
hold the truename of the pathname of the file being loaded.
*COMPILE-FILE-TRUENAME* [Variable]
This special variable is initially NIL, but is bound by
COMPILE-FILE to hold the truename of the pathname of the file
being compiled.
*LOAD-PATHNAME* [Variable]
This special variable is initially NIL, but is bound by LOAD to
hold the pathname of the file being loaded.
*COMPILE-FILE-PATHNAME* [Variable]
This special variable is initially NIL, but is bound by
COMPILE-FILE to hold the pathname of the file being compiled.
Example:
------ File SETUP ------
(IN-PACKAGE 'MY-STUFF)
(DEFMACRO COMPILE-TRUENAME () `',*COMPILE-FILE-TRUENAME*)
(DEFVAR *SOURCE-FILE* (COMPILE-TRUENAME) "Just for debugging.")
(DEFVAR *LOADED-FILE* *LOAD-TRUENAME*)
(DEFUN LOAD-MY-SYSTEM ()
(DOLIST (MODULE-NAME '("FOO" "BAR" "BAZ"))
(LOAD (MERGE-PATHNAMES MODULE-NAME *LOAD-TRUENAME*))))
------------------------
(LOAD "SETUP")
(LOAD-MY-SYSTEM)
Rationale:
This satisfies the most common instances of the frequently reported
problem in the Problem Description.
Current Practice:
Wide variation.
In some implementations, calling LOAD binds or sets
*DEFAULT-PATHNAME-DEFAULTS* so that pathnames named in a file being
LOADed will default to being `nearby.'
Some implementations provide special variables that are similar or
identical to one or both of those proposed.
Some implementations have a way to represent the pathname for the
current working directory, and make the default pathname default
to that, so that loading without specifying a default again tends to
get `nearby' files.
None of these techniques is portable, unfortunately, because there
is no agreement.
Cost to Implementors:
Very small.
Cost to Users:
None. This change is upward compatible.
Cost of Non-Adoption:
Continued difficulty for anyone trying to put a system of modules
in a form where they can be conveniently delivered using portable code.
Benefits:
The cost of non-adoption is avoided.
Aesthetics:
Negligible.
Discussion:
Touretzky raised the issue most recently on Common-Lisp. A number
of people immediately jumped on the bandwagon, indicating it was
important to them, too.
Pitman made three suggestions in response, of which the above is
the first. The others included:
2. Variables *LOAD-TRUENAMES* and *COMPILE-FILE-TRUENAMES* which hold
lists of the truenames of all files being loaded or compiled,
respectively, during the dynamic invocation of LOAD and COMPILE-FILE.
3. Variable *LOAD-OR-COMPILE-FILE-TRUENAMES* which holds a list like
((LOAD truename) (COMPILE-FILE truename) ...)
during the dynamic invocation of LOAD and COMPILE-FILE.
Touretzky responded:
``I like KMP's proposals. I like the second one best: have separate
variables for files being loaded and files being compiled, and use
them to maintain a stack so we can see the nesting of loads within
files.''
Pitman ultimately chose to present the first rather than the second
because it seemed simpler, easier to explain, and more likely to
pass at this late date.
!
Additional Comments:
"I favor LOAD-TRUENAME:NEW-PATHNAME-VARIABLES. I think this
proposal would be greatly improved by adding two more variables,
*LOAD-PATHNAME* and *COMPILE-FILE-PATHNAME*, whose values are
the pathname opened by LOAD or COMPILE-FILE, rather than the
truename. The need for these is more obvious if you think
about systems where the pathname cannot be easily reconstructed
from the truename. This includes file systems with symbolic
links and some pathname systems with logical pathnames."
"I favor this. I would even favor either of the other two ideas even at
this `late date'. The behavior of each of the proposals is simple, its
easy to see what it will and won't do, and it satisfies a real demand.
I should note that I have never wanted the incremented functionally
offered by the `stack' proposals, but I could still vote for them."
∂29-Mar-89 1550 CL-Cleanup-mailer Issue: DESTRUCTURING-BIND, v.3
Received: from ctc.contel.com (goofy.ctc.contel.com) by SAIL.Stanford.EDU with TCP; 29 Mar 89 15:50:01 PST
Received: from mickey.ctc.contel.com by ctc.contel.com (4.0/870914.1{Enger})
id AA11389; Wed, 29 Mar 89 18:50:08 EST
Received: by mickey.ctc.contel.com (4.0/SMI-4.0)
id AA01917; Wed, 29 Mar 89 18:51:15 EST
Date: Wed, 29 Mar 89 18:51:15 EST
Message-Id: <8903292351.AA01917@mickey.ctc.contel.com>
To: cl-cleanup@sail.stanford.edu
Subject: Issue: DESTRUCTURING-BIND, v.3
From: moon@symbolics.com
Issue: DESTRUCTURING-BIND
Forum: Cleanup
References: DEFMACRO (CLtL pp145-151),
The LOOP Facility (X3J13/89-004)
Category: ADDITION
Edit history: 24-Jan-89, Version 1 by Pitman
25-Jan-89, Version 2 by Pitman
29-Mar-89, Version 3, by Moon, amended based on poll
Problem Description:
Common Lisp programmers have frequently complained that the
destructuring facility used by DEFMACRO is not made available
for use in ordinary programming situations involving list data.
The presence of a destructuring facility in the recently adopted
LOOP facility will be likely to make the absence of a separable
destructuring facility all the more apparent.
Prior to the introduction of LET into Maclisp, many people wrote
their own LET macros. A popular expansion was in terms of a DO
which did not iterate. eg,
(LET ((A 3)) (+ A A)) ==> (DO ((A 3)) () (RETURN (+ A A)))
While this practice `worked,' it was not perspicuous and contributed
substantially to non-readability: not only were the macros hard to
understand, but the surface interface itself was not standardized
and varied in subtle ways. For example, some LET macros allowed GO
statements while others did not.
There is now considerable danger that a lot of people will write
DESTRUCTURING-BIND variants in terms of a LOOP expression that
immediately returns.
(DESTRUCTURING-BIND ((A B) C) (FOO) (LIST A B C))
==> (LOOP FOR ((A B) C) ON (FOO) DO (RETURN (LIST A B C)))
Since the destructuring offered by LOOP is different in subtle ways
from the destructuring offered by DESTRUCTURING-BIND in implementations
offering that primitive natively, gratuitous headaches could result.
Proposal (DESTRUCTURING-BIND:NEW-MACRO):
Provide a macro called DESTRUCTURING-BIND which behaves like the
destructuring bind in DEFMACRO. Specifically...
DESTRUCTURING-BIND lambda-list expression {decl}* {form}* [Macro]
Binds the variables specified in LAMBDA-LIST to the corresponding
values in the tree structure resulting from evaluating EXPRESSION,
then evaluates the FORMS in the body.
Anywhere in the LAMBDA-LIST where a parameter name may appear, and
where ordinary lambda-list syntax (as described in CLtL section 5.2.2)
does not otherwise allow a list, a lambda-list may appear in place of
the parameter name. When this is done, then the argument form that
would match the parameter is treated as a (possibly dotted) list, to
be used as an argument forms list for satisfying the parameters in
the embedded lambda-list.
If any of the lambda list keywords &OPTIONAL, &REST, &KEY,
&ALLOW-OTHER-KEYS and &AUX appears in the lambda list, it is treated
as with any other lambda-list.
If the lambda list keyword &BODY appears, it is treated as a synonym
for &REST.
The lambda list keyword &ENVIRONMENT is not allowed.
If the lambda list keyword &WHOLE appears, it must be followed by a
single variable that is bound to the entire expression at the current
level. &WHOLE and its following variable should appear first in the
list, before any other parameter or lambda-list keyword.
It is also permissible for any level of the LAMBDA-LIST to be dotted,
ending in a parameter name. This situation is treaed exactly as if
the aprameter name that ends the list had appeared preceded by &REST
in a proper list. For example, the notation (X Y . Z) is equivalent
to (X Y &REST Z).
If the result of evaluating the expression does not match the
destructuring pattern, an error should be signaled.
Test Case:
(DEFUN IOTA (N) (LOOP FOR I FROM 1 TO N COLLECT I)) ;helper
(DESTRUCTURING-BIND ((A &OPTIONAL (B 'BEE)) ONE TWO THREE)
`((ALPHA) ,@(IOTA 3))
(LIST A B THREE TWO ONE))
=> (ALPHA BEE 3 2 1)
Rationale:
The proposal directly addresses the stated problem, and is current practice
in numerous implementations. Our charter effectively dictates that where
feasible we should try to head off the widespread development of uselessly
different variants of commonplace tools.
The intent of the specification is to make DESTRUCTURING-BIND lambda-lists
compatible with inner-list elements of a macro lambda-list.
Current Practice:
Symbolics Genera, Envos Medley, TI Explorer, and Lucid CL all offer
DESTRUCTURING-BIND, though the details vary slightly.
The DESTRUCTURING-BIND offered by Symbolics Genera signals an error if
the pattern is not matched. The TI Explorer version does not.
Cost to Implementors:
Very small. In most cases, it's a matter of renaming and/or exporting an
already existing symbol. In a few cases, a very small amount of
`program interface' code would have to be written.
Cost to Users:
None. This is an upward compatible change.
Cost of Non-Adoption:
Loss of the Benefits and Aesthetics cited below.
Benefits:
Users will get a powerful feature they have asked for on many occassions.
In implementations which `autoload' code, it would be better for this
support to be separable so that people could do DESTRUCTURING-BIND
without demand loading all other LOOP support.
Aesthetics:
Defining this macro centrally for the Common Lisp community will reduce
subtle deviations, which will in turn have positive aesthetic impact.
Discussion:
JonL observes that although LOOP does destructuring, it can't directly
make use of the DESTRUCTURING-BIND interface suggested here.
Pitman and Gray think a facility of this sort is a good idea, though
obviously the details may still need a little fleshing out before the
proposal is ready for vote.
To date, the excuse for not satisfying this request has been a
religious war between factions who want to destructure lists by
writing
(DESTRUCTURING-BIND (var1 var2 var3) exp . body)
and those who want to destructure lists by writing
(DESTRUCTURING-BIND (LIST var1 var2 var3) exp . body)
The advantage of the former approach is that it is notationally
concise for the common case of destructuring a list. The disadvantage
is that it is not extensible to accomodate abstract kinds of
destructuring.
The advantage of the latter approach is that it allows interesting
extensions that accomodate data-hiding, such as:
(DEFMACRO MAKE-FOO (&REST ELEMENTS) `(LIST ,@ELEMENTS))
(DESTRUCTURING-BIND (MAKE-FOO var1 var2 var3) exp . body)
and later the ability to change the representation of a FOO without
updating the associated binding forms. The disadvantage is that it
is more verbose in the common case of destructuring a list, and still
even more verbose for nested lists.
Although destructuring has always existed in DEFMACRO, this has not
been adequate precedence for deciding the outcome of the religious war
because DEFMACRO only needs to destructure programs, and programs are
generally made up only of lists -- not arbitrary user-defined abstract
data types.
The lambda-list form of DESTRUCTURING-BIND in this version is
not completely compatible with the destructuring done by LOOP
in three areas: LOOP allows NIL elements of a list to be ignored,
LOOP does not allow &-keywords, and LOOP destructuring ignores
extra elements in the list being matched.
∂04-Apr-89 0804 CL-Cleanup-mailer Issue: ADJUST-ARRAY-NOT-ADJUSTABLE
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 4 Apr 89 08:04:40 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 570859; Tue 4-Apr-89 11:04:34 EDT
Date: Tue, 4 Apr 89 11:04 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: ADJUST-ARRAY-NOT-ADJUSTABLE
To: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <890404110402.9.KMP@BOBOLINK.SCRC.Symbolics.COM>
My notes say this was deferred to next meeting.
∂04-Apr-89 0805 CL-Cleanup-mailer Issue: BREAK-ON-WARNINGS-OBSOLETE
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 4 Apr 89 08:05:10 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 570860; Tue 4-Apr-89 11:05:11 EDT
Date: Tue, 4 Apr 89 11:04 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: BREAK-ON-WARNINGS-OBSOLETE
To: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <890404110447.0.KMP@BOBOLINK.SCRC.Symbolics.COM>
My notes say this passed unanimously with friendly amendment to
"remove" rather than "deprecate".
∂04-Apr-89 0805 CL-Cleanup-mailer Issue: CLOS-CONDITIONS
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 4 Apr 89 08:05:45 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 570862; Tue 4-Apr-89 11:05:44 EDT
Date: Tue, 4 Apr 89 11:05 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: CLOS-CONDITIONS
To: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <890404110518.1.KMP@BOBOLINK.SCRC.Symbolics.COM>
My notes say this passed on a vote of N-0-3.
∂04-Apr-89 0808 CL-Cleanup-mailer Issue: CLOS-MACRO-COMPILATION
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 4 Apr 89 08:08:08 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 570863; Tue 4-Apr-89 11:08:06 EDT
Date: Tue, 4 Apr 89 11:07 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: CLOS-MACRO-COMPILATION
To: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <890404110742.2.KMP@BOBOLINK.SCRC.Symbolics.COM>
My notes say that several amendments by Gregor were discussed but eventually
the issue was tabled until the next meeting. (A new version should be written
incorporating those amendments.)
Moon's notes add that on the issue of when forms are evaluated, Gregor's
amendment covered it for EQL parameter specializer names, but not for
DEFCONSTANT; perhaps DEFCONSTANT should be brought up as another cleanup.
∂04-Apr-89 0809 CL-Cleanup-mailer Issue: CLOSED-STREAM-OPERATIONS
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 4 Apr 89 08:09:00 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 570864; Tue 4-Apr-89 11:09:01 EDT
Date: Tue, 4 Apr 89 11:08 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: CLOSED-STREAM-OPERATIONS
To: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <890404110837.3.KMP@BOBOLINK.SCRC.Symbolics.COM>
My notes say...
A motion to reconsider this issue passed N-2.
A motion to revoke version 7 and replace it with version 5 was made.
Walter van Roggen proposed we amend it to make all CLOSE return values
unspecified.
The motion to amend failed on a 3-4-N vote.
A recount was requested because people aren't permitted to abstain on
technical issues.
The motion still failed on a 6-8 vote.
The original motion (to replace v7 with v5) passed unamended 12-0.
∂04-Apr-89 0809 CL-Cleanup-mailer Issue: COERCE-INCOMPLETE
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 4 Apr 89 08:09:35 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 570867; Tue 4-Apr-89 11:09:31 EDT
Date: Tue, 4 Apr 89 11:09 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: COERCE-INCOMPLETE
To: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <890404110907.4.KMP@BOBOLINK.SCRC.Symbolics.COM>
My notes say that someone made a motion for option DEPRECATE but it
died for lack of a second. This issue was marked withdrawn.
∂04-Apr-89 0816 CL-Cleanup-mailer Issue: COMMON-TYPE
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 4 Apr 89 08:10:06 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 570871; Tue 4-Apr-89 11:10:01 EDT
Date: Tue, 4 Apr 89 11:09 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: COMMON-TYPE
To: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <890404110930.5.KMP@BOBOLINK.SCRC.Symbolics.COM>
My notes say this passed unanimously.
∂04-Apr-89 0817 CL-Cleanup-mailer Issue: COMPILE-FILE-SYMBOL-HANDLING
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 4 Apr 89 08:13:56 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 570885; Tue 4-Apr-89 11:13:56 EDT
Date: Tue, 4 Apr 89 11:13 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: COMPILE-FILE-SYMBOL-HANDLING
To: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <890404111332.7.KMP@BOBOLINK.SCRC.Symbolics.COM>
Moon's notes (mine were less complete) say there was disagreement about
which approach was worthwhile, so the committee will pursue option
REQUIRE-CONSISTENCY. They will delete ``must ensure'' since that is in
general impossible. People were asked to comment in mail (on the issue
of where SELECT-PACKAGE can go?).
This was deferred to next meeting.
∂04-Apr-89 0817 CL-Cleanup-mailer Issue: COMPILE-ENVIRONMENT-CONSISTENCY
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 4 Apr 89 08:11:16 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 570878; Tue 4-Apr-89 11:11:16 EDT
Date: Tue, 4 Apr 89 11:10 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: COMPILE-ENVIRONMENT-CONSISTENCY
To: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <890404111052.6.KMP@BOBOLINK.SCRC.Symbolics.COM>
My notes say
``Gregor--Omit (g) 2nd sentence and say "structure or deftype" type specs''
Moon's notes agree and add
``For defclass, no info is compiled in, so superclass, metaclass, slots
can be different at load time. Change 3rd sentence not to apply to
DEFCLASS-defined types.''
This was tabled.
I also have a note to myself that I wondered if NOTINLINE and the FTYPE
declaration restrictions should interact.
∂04-Apr-89 0823 CL-Cleanup-mailer COMPILE-FILE-SYMBOL-HANDLING, COMPILE-ENVIRONMENT-CONSISTENCY
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 4 Apr 89 08:23:23 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 570902; Tue 4-Apr-89 11:23:20 EDT
Date: Tue, 4 Apr 89 11:22 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: COMPILE-FILE-SYMBOL-HANDLING, COMPILE-ENVIRONMENT-CONSISTENCY
To: CL-Cleanup@SAIL.Stanford.EDU
References: <890404111332.7.KMP@BOBOLINK.SCRC.Symbolics.COM>,
<890404111052.6.KMP@BOBOLINK.SCRC.Symbolics.COM>
Message-ID: <890404112256.0.KMP@BOBOLINK.SCRC.Symbolics.COM>
Oops--wrong list. Those were compiler issues. Please ignore them. Thanks.
∂04-Apr-89 0832 CL-Cleanup-mailer Issue: COMPLEX-RATIONAL-RESULT
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 4 Apr 89 08:32:12 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 570916; Tue 4-Apr-89 11:32:14 EDT
Date: Tue, 4 Apr 89 11:31 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: COMPLEX-RATIONAL-RESULT
To: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <890404113150.1.KMP@BOBOLINK.SCRC.Symbolics.COM>
My notes say this passed n-0-2.
∂04-Apr-89 0833 CL-Cleanup-mailer Issue: CONDITION-RESTARTS
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 4 Apr 89 08:33:21 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 570918; Tue 4-Apr-89 11:33:23 EDT
Date: Tue, 4 Apr 89 11:32 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: CONDITION-RESTARTS
To: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <890404113259.2.KMP@BOBOLINK.SCRC.Symbolics.COM>
My notes say this wasn't ready for a vote.
GZ wants us to flush COPY-CONDITION, which we're already planning to do.
IIM wants a :TEST keyword for restarts to allow them to selectively apply.
Loosemore wants not to forbid resignalling or any new version should relate
itself to item 3 of COMPILER-DIAGNOSTICS, which discusses resignalling.
Deferred to next meeting.
∂04-Apr-89 0834 CL-Cleanup-mailer Issue: COPY-SYMBOL-COPY-PLIST
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 4 Apr 89 08:34:19 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 570919; Tue 4-Apr-89 11:34:14 EDT
Date: Tue, 4 Apr 89 11:33 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: COPY-SYMBOL-COPY-PLIST
To: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <890404113350.3.KMP@BOBOLINK.SCRC.Symbolics.COM>
My notes say this passed unanimously.
∂04-Apr-89 0834 CL-Cleanup-mailer Issue: COPY-SYMBOL-COPY-PRINT-NAME
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 4 Apr 89 08:34:43 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 570920; Tue 4-Apr-89 11:34:43 EDT
Date: Tue, 4 Apr 89 11:34 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: COPY-SYMBOL-COPY-PRINT-NAME
To: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <890404113419.4.KMP@BOBOLINK.SCRC.Symbolics.COM>
My notes say this passed unanimously.
∂04-Apr-89 0835 CL-Cleanup-mailer Issue: DECLARE-FUNCTION-AMBIGUITY
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 4 Apr 89 08:35:21 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 570921; Tue 4-Apr-89 11:35:24 EDT
Date: Tue, 4 Apr 89 11:35 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: DECLARE-FUNCTION-AMBIGUITY
To: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <890404113500.5.KMP@BOBOLINK.SCRC.Symbolics.COM>
There was confusion about how this had worked out at the late meeting.
An incredibly weird vote on the question ``How many favor saying it passed
at the last meeting?'' passed N-0-M.
∂04-Apr-89 0842 CL-Cleanup-mailer Issue: DEFINE-OPTIMIZER
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 4 Apr 89 08:42:28 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 570934; Tue 4-Apr-89 11:42:22 EDT
Date: Tue, 4 Apr 89 11:41 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: DEFINE-OPTIMIZER
To: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <890404114158.6.KMP@BOBOLINK.SCRC.Symbolics.COM>
After some fooling around with various amendments, this was brought to
a vote with the names DEFINE-COMPILER-MACRO (and I guess
COMPILER-MACROEXPAND and COMPILER-MACROEXPAND-1, though I realized later
that it was never made explicit) and failed 8-11-0.
I believe the issue may get re-opened. The reason is that I recently
realized that (a) users cannot write thing that ``should signal''
and (b) all they need to write things that ``should signal'' is
this functionality plus that provided in SYNTACTIC-ENVIRONMENT-ACCESS.
That's all I have to say for now. But don't be surprised if I have more
to say later.
∂04-Apr-89 0852 CL-Cleanup-mailer Issue: DEFMACRO-LAMBDA-LIST
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 4 Apr 89 08:52:40 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 570949; Tue 4-Apr-89 11:52:39 EDT
Date: Tue, 4 Apr 89 11:52 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: DEFMACRO-LAMBDA-LIST
To: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <890404115215.9.KMP@BOBOLINK.SCRC.Symbolics.COM>
There were hardcopy amendments distributed. The hardcopy said:
Proposed amendments to DEFMACRO-LAMBDA-LIST KMP 3/30/89
(from MLY)
A. [Friendly] In 1b, change "may only appear at any level"
to "may appear at any level".
B. [Vote separately]
1. Prohibit/Permit (&whole W &environment E A B)
2. Prohibit/Permit (&environment E &whole W A B)
3. Prohibit/Permit (&whole W A B &environment E)
4. Prohibit/Permit (&whole W A &environment E B)
My notes say that we approved amendments A & B (``permit all four'')
and we added an amendment that said that &ENVIRONMENT would not be
duplicated in a DEFMACRO lambda-list.
The amended proposal was passed N-0-1.
∂04-Apr-89 0855 CL-Cleanup-mailer Issue: DEFMACRO-LAMBDA-LIST
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 4 Apr 89 08:54:55 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 570953; Tue 4-Apr-89 11:54:56 EDT
Date: Tue, 4 Apr 89 11:54 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: DEFMACRO-LAMBDA-LIST
To: CL-Cleanup@SAIL.Stanford.EDU
Supersedes: <890404115215.9.KMP@BOBOLINK.SCRC.Symbolics.COM>
Message-ID: <890404115432.0.KMP@BOBOLINK.SCRC.Symbolics.COM>
There were hardcopy amendments distributed. The hardcopy said:
Proposed amendments to DEFMACRO-LAMBDA-LIST KMP 3/30/89
(from MLY)
A. [Friendly] In 1b, change "may only appear at any level"
to "may appear at any level".
B. [Vote separately]
1. Prohibit/Permit (&whole W &environment E A B) ``After &Whole''
2. Prohibit/Permit (&environment E &whole W A B) ``Before &Whole''
3. Prohibit/Permit (&whole W A B &environment E) ``Last''
4. Prohibit/Permit (&whole W A &environment E B) ``Middle''
My notes say that we approved amendments A & B (``permit all four'')
and we added an amendment that said that &ENVIRONMENT would not be
duplicated in a DEFMACRO lambda-list.
The amended proposal was passed N-0-1.
∂04-Apr-89 0855 CL-Cleanup-mailer Issue: DESCRIBE-UNDERSPECIFIED
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 4 Apr 89 08:55:17 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 570954; Tue 4-Apr-89 11:55:17 EDT
Date: Tue, 4 Apr 89 11:54 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: DESCRIBE-UNDERSPECIFIED
To: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <890404115453.1.KMP@BOBOLINK.SCRC.Symbolics.COM>
An amendment was made (I think by Barrett) to make DESCRIBE deal with
its second argument in the same way as PRINT does (that is, permitting
arguments of NIL and T).
The amended proposal passed 15-0.
∂04-Apr-89 0857 CL-Cleanup-mailer Issue: DESTRUCTURING-BIND
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 4 Apr 89 08:57:16 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 570958; Tue 4-Apr-89 11:57:09 EDT
Date: Tue, 4 Apr 89 11:56 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: DESTRUCTURING-BIND
To: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <890404115645.2.KMP@BOBOLINK.SCRC.Symbolics.COM>
My notes say that discussion on this was broken over two days with
quite a number of possible amendments discussed.
I came up with a written set of amendments for Thursday which were
discarded because Moon submitted a coherent revised proposal
(consistent with those amendments, and adding at least one other
feature not covered in those separate amendments) on Thursday.
The revised proposal was Moon's v3, already mailed.
The revised proposal was voted on, and passed 15-1.
∂04-Apr-89 1027 CL-Cleanup-mailer issue DYNAMIC-EXTENT-FUNCTION, version 1
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 4 Apr 89 10:27:27 PDT
Received: from defun.utah.edu by cs.utah.edu (5.61/utah-2.1-cs)
id AA29744; Tue, 4 Apr 89 11:27:25 -0600
Received: by defun.utah.edu (5.61/utah-2.0-leaf)
id AA19101; Tue, 4 Apr 89 11:27:23 -0600
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8904041727.AA19101@defun.utah.edu>
Date: Tue, 4 Apr 89 11:27:21 MDT
Subject: issue DYNAMIC-EXTENT-FUNCTION, version 1
To: cl-cleanup@sail.stanford.edu
As promised, here's a first cut at this issue. I'm not particularly
attached to the name DYNAMIC-EXTENT-FUNCTION, but I'm still feeling
too burned out from arguing over what to rename DEFPROCLAIM to want to
waste a lot of time on thinking up alternate names for this one too. :-(
Forum: CLEANUP
Issue: DYNAMIC-EXTENT-FUNCTION
References: Scope and Extent
Issue DYNAMIC-EXTENT
Category: ADDITION
Edit history: 04-Apr-89, Version 1 by Loosemore
Problem Description:
Proposal DYNAMIC-EXTENT:NEW-DECLARATION, passed at the March 89
meeting, provides a mechanism for declaring that the values of
variables have only dynamic (rather than indefinite) extent. It
would be useful to have similar functionality to indicate that
functional bindings may have only dynamic extent. (For example,
this would permit compilers to stack-allocate closures.)
Proposal (DYNAMIC-EXTENT:NEW-DECLARATION):
Introduce a new declaration called DYNAMIC-EXTENT-FUNCTION. This is
identical to the DYNAMIC-EXTENT declaration, except that the
arguments name functions instead of variables.
Rationale:
This permits a programmer to offer advice to an implementation about
what functions may be stack-allocated for efficiency.
It may be difficult or impossible for a compiler to infer this
same information statically.
Current Practice:
JonL says that Lucid's compiler can stack-allocate closures, but they
have no mechanism for programmers to give the compiler permission to
do so.
HPCL-I has an UPWARD-CLOSURES declaration that pervasively affects
all closures created within the scope of the declaration.
Cost to Implementors:
No cost is forced since implementations are permitted to simply
ignore the DYNAMIC-EXTENT-FUNCTION declaration.
Cost to Users:
None. This change is upward compatible.
There may be some hidden costs to debugging using this declaration (or any
feature which permits the user to access dynamic extent objects without
the compiler proving that they are appropriate). If the user misdeclares
something and returns a pointer into the stack (or stores it in the heap),
an undefined situation may result and the integrity of the Lisp storage
mechanism may be compromised. Debugging these situations may be tricky,
but users who have asked for this feature have indicated a willingness
to deal with such costs. Nevertheless, the perils should be clearly
documented and casual users should not be encouraged to use this
declaration.
Cost of Non-Adoption:
Some portable code would be forced to run more slowly (due to
GC overhead), or to use non-portable language features.
Benefits:
The cost of non-adoption is avoided.
Aesthetics:
This declaration allows a fairly low level optimization to work
by asking the user to provide only very high level information.
The alternatives (sharpsign conditionals, some of which may
lead to more bit-picky abstractions) are far less aesthetic.
Discussion:
Loosemore supports DYNAMIC-EXTENT-FUNCTION:NEW-DECLARATION.
-------
∂04-Apr-89 1110 CL-Cleanup-mailer Issue: DYNAMIC-EXTENT
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 4 Apr 89 11:10:38 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 571083; Tue 4-Apr-89 14:10:29 EDT
Date: Tue, 4 Apr 89 14:10 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: DYNAMIC-EXTENT
To: CL-Cleanup@SAIL.Stanford.EDU
cc: sandra%defun@CS.Utah.EDU
Message-ID: <890404141003.4.KMP@BOBOLINK.SCRC.Symbolics.COM>
Sandra and Gabriel initially claimed to oppose this even in principle.
However, Steele and I drafted a revised proposal over lunch Thursday.
The text of the revised proposal was:
GLS and KMP 3/30/89
Amendment to DYNAMIC-EXTENT:NEW-DECLARATION
* Strike sentences 3 and 4 of paragraph 1.
* Move paragraphs 3 through n-1 to the examples.
* Strike last paragraph.
* Add this text after paragraph 1:
_Definition_: Object _x_ is an _otherwise_inaccessible_part_ (OIP)
of _y_ iff making _y_ inaccessible would make _x_ inaccessible.
(Note that every object is an OIP of itself.)
Suppose that construct _c_ contains a DYNAMIC-EXTENT declaration
for variable _v_ (which need not be bound by _c_). Consider the
values _w1_, ..., _wN_ taken on by _v_ during the course of some
execution of _c_. The declaration asserts that if object _x_ is
an OIP of _wI_ when _wI_ ever becomes the value of _v_, then
just after execution of _c_ terminates _x_ will be either
inaccessible or still an OIP of _v_.
The proposal was also amended in the meeting to say:
"If the assertion is ever violated, the conseqeuences are undefined."
The fully amended proposal passed 17-0.
It was generally agreed that we would also like to consider a proposal
on dynamic extent functions at the next meeting. (Sandra said she would
prepare one, and has already done so. See issue DYNAMIC-EXTENT-FUNCTION.)
∂04-Apr-89 1111 CL-Cleanup-mailer Issue: EQUALP-GENERIC
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 4 Apr 89 11:11:49 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 571085; Tue 4-Apr-89 14:11:46 EDT
Date: Tue, 4 Apr 89 14:11 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: EQUALP-GENERIC
To: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <890404141117.5.KMP@BOBOLINK.SCRC.Symbolics.COM>
My notes say this issue was withdrawn by Barrett.
∂04-Apr-89 1114 CL-Cleanup-mailer Issue: ERROR-CHECKING-IN-NUMBERS-CHAPTER
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 4 Apr 89 11:14:07 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 571087; Tue 4-Apr-89 14:13:58 EDT
Date: Tue, 4 Apr 89 14:13 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: ERROR-CHECKING-IN-NUMBERS-CHAPTER
To: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <890404141334.6.KMP@BOBOLINK.SCRC.Symbolics.COM>
My notes show the following...
The major roadblocks were that GZ (and a few others) were hung up on the
presentation of ``should signal.''
GZ cited the example of (LOCALLY (DECLARE (OPTIMIZE (SAFETY 0))) #'+).
She wanted to know if the resulting function could fail to do error checking.
(RPG and KMP will pursue this.)
JonL really hated the presentation of the boole arguments using #.
RWK said we should definitely do this kind of stuff (error type identification)
now if possible, and not wait for the next standard.
Walter van Roggen was worried that some of this stuff might be controversial,
but I assured him that we would back off to a more vague error type
rather than dispute endlessly about controversial cases. He seemed happy with
that.
Haflich seemed to believe that this was especially important for numbers, so
he was happy to see this chapter done.
Masinter said that with his implementor's hat on, he thought this was a pain,
but that with his user's hat on, he liked it. He was letting his user side
dominate and being very supportive.
There was consensus that we should discuss this (and similar proposals) at
the next meeting.
∂04-Apr-89 1115 CL-Cleanup-mailer Issue: ERROR-NOT-HANDLED
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 4 Apr 89 11:15:19 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 571089; Tue 4-Apr-89 14:15:16 EDT
Date: Tue, 4 Apr 89 14:14 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: ERROR-NOT-HANDLED
To: CL-Cleanup@SAIL.Stanford.EDU
cc: chapman%aitg.dec@decwrl.dec.com
Message-ID: <890404141451.7.KMP@BOBOLINK.SCRC.Symbolics.COM>
My notes say this issue was withdrawn in favor of providing Kathy with
editorial advice to `minimize implicit requirements on debuggers' in the
presentation of the debugger in the standard.
Kathy- if the implication of that is not clear, let me know privately
and I'll help you get that in order.
∂04-Apr-89 1117 CL-Cleanup-mailer Issue: FUNCTION-COERCE-TIME
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 4 Apr 89 11:16:47 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 571092; Tue 4-Apr-89 14:16:48 EDT
Date: Tue, 4 Apr 89 14:16 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: FUNCTION-COERCE-TIME
To: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <890404141624.9.KMP@BOBOLINK.SCRC.Symbolics.COM>
My notes show this as withdrawn.
The editors were instructed to be explicitly vague 16-1.
∂04-Apr-89 1125 CL-Cleanup-mailer Issue: EXIT-EXTENT
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 4 Apr 89 11:16:19 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 571091; Tue 4-Apr-89 14:16:18 EDT
Date: Tue, 4 Apr 89 14:15 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: EXIT-EXTENT
To: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <890404141553.8.KMP@BOBOLINK.SCRC.Symbolics.COM>
This was characterized by someone as ``the unstoppable throw meeting the
immovable catch.''
I offered a "one time only" offer to support option MINIMAL if we could
just get this off the table this week and not keep deferring it.
Moon offered some amendments the effect of which were to allow you to throw again
to the same tag as you were already throwing to; specifically:
In the first paragraph of the MINIMAL proposal, delete "or is itself the
target exit" and change "events (c) and (d) at" to "event (c) occurs at".
After the first paragraph add a new paragraph "The event (d) occurs at the
end of the transfer of control."
The proposal was amended, and the amended option MINIMAL passed 11-5.
∂04-Apr-89 1127 CL-Cleanup-mailer Re: Issue: DYNAMIC-EXTENT
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 4 Apr 89 11:26:13 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 571107; 4 Apr 89 14:21:42 EDT
Date: Tue, 4 Apr 89 14:21 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: Issue: DYNAMIC-EXTENT
To: sandra%defun@cs.utah.edu
cc: KMP@STONY-BROOK.SCRC.Symbolics.COM, CL-Cleanup@SAIL.Stanford.EDU
In-Reply-To: <8904041817.AA19138@defun.utah.edu>
Message-ID: <890404142113.2.KMP@BOBOLINK.SCRC.Symbolics.COM>
Date: Tue, 4 Apr 89 12:17:17 MDT
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
> Sandra and Gabriel initially claimed to oppose this even in principle.
Gack -- I've been misquoted! The principle is fine with me and the
revision fixed the thing that bugged me the most (making the
declaration apply to *any* value assigned to the variable instead of
just its initial value) about the original proposal.
Ok, I stand corrected -- and I'm glad to see you're happy with what
we decided.
The whole reason I'm distributing this stuff is to make sure my view of
what happened aligns with other people's. I guess if it's catching
discrepancies, that's a sign that the process is worthwhile. :-}
∂04-Apr-89 1127 CL-Cleanup-mailer Issue: FUNCTION-NAME
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 4 Apr 89 11:17:21 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 571095; Tue 4-Apr-89 14:17:15 EDT
Date: Tue, 4 Apr 89 14:16 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: FUNCTION-NAME
To: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <890404141651.0.KMP@BOBOLINK.SCRC.Symbolics.COM>
My notes show the following...
We voted in order SMALL, MEDIUM, then LARGE.
Each time, the attempt was to replace the previous.
Option SMALL passed 15-2.
Option MEDIUM passed 9-6, superseding SMALL.
Option LARGE passed 13-2-3, superseding MEDIUM.
The minutes probably just reflect LARGE having been passed.
Moon then moved that we reconsider parts of LARGE -- parts 4,7,8,9.
We agreed to reconsider.
Sandra moved to retract 4,7,8,9.
RPG amended the proposal to affect GENERIC-FLET and GENERIC-LABELS, too,
for consistency.
RPG's amendment to Sandra's motion passed.
We voted on each part of Sandra's motion separately:
Strike 4? No. (Failed 3-15)
Strike 7? Yes. (Passed 16-1)
Strike 8? Yes. (Passed 16-0)
Strike 9? Yes (Passed 17-0-1)
There was some question about 9's relation to SYNTACTIC-ENVIRONMENT-ACCESS.
The net effect is that option LARGE passed with amendments to strike 7,8,9.
∂04-Apr-89 1133 CL-Cleanup-mailer Re: Issue: DYNAMIC-EXTENT
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 4 Apr 89 11:17:25 PDT
Received: from defun.utah.edu by cs.utah.edu (5.61/utah-2.1-cs)
id AA02524; Tue, 4 Apr 89 12:17:20 -0600
Received: by defun.utah.edu (5.61/utah-2.0-leaf)
id AA19138; Tue, 4 Apr 89 12:17:18 -0600
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8904041817.AA19138@defun.utah.edu>
Date: Tue, 4 Apr 89 12:17:17 MDT
Subject: Re: Issue: DYNAMIC-EXTENT
To: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Cc: CL-Cleanup@SAIL.Stanford.EDU, sandra%defun@cs.utah.edu
In-Reply-To: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>, Tue, 4 Apr 89 14:10 EDT
> Sandra and Gabriel initially claimed to oppose this even in principle.
Gack -- I've been misquoted! The principle is fine with me and the
revision fixed the thing that bugged me the most (making the
declaration apply to *any* value assigned to the variable instead of
just its initial value) about the original proposal.
-Sandra
-------
∂04-Apr-89 1133 CL-Cleanup-mailer Issue: GENSYM-NAME-STICKINESS
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 4 Apr 89 11:17:42 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 571096; Tue 4-Apr-89 14:17:43 EDT
Date: Tue, 4 Apr 89 14:17 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: GENSYM-NAME-STICKINESS
To: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <890404141718.1.KMP@BOBOLINK.SCRC.Symbolics.COM>
Option LIKE-TEFLON passed 17-0.
There was general agreement that the issue name was an example of good marketing
and helped the proposal slide right through.
∂04-Apr-89 1147 CL-Cleanup-mailer Issue: HASH-TABLE-ACCESS
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 4 Apr 89 11:47:01 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 571158; Tue 4-Apr-89 14:46:59 EDT
Date: Tue, 4 Apr 89 14:46 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: HASH-TABLE-ACCESS
To: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <890404144633.3.KMP@BOBOLINK.SCRC.Symbolics.COM>
My notes say this passed 17-0 with hand-written amendments by me
(and agreement that the `obvious' write-o's would be corrected).
The [corrected] hand-written text says:
Amendment to HASH-TABLE-ACCESS KMP 3/30/89
Add: Define that the results of HASH-TABLE-REHASH-SIZE,
HASH-TABLE-REHASH-THRESHOLD, and HASH-TABLE-SIZE
are suitable for use in a call to MAKE-HASH-TABLE
in order to produce a hash table with state
corresponding to the current state of the hash table.
Clarify that the result of HASH-TABLE-TEST is always a
symbol naming a function rather than the function itself if
the test is one of those defined by this standard.
(Implementations which provide additional tests for hash
tables may determine how this function relates to such
extended tests.)
∂04-Apr-89 1148 CL-Cleanup-mailer Issue: HASH-TABLE-SIZE
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 4 Apr 89 11:48:15 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 571161; 4 Apr 89 14:47:57 EDT
Date: Tue, 4 Apr 89 14:47 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: HASH-TABLE-SIZE
To: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <890404144729.4.KMP@BOBOLINK.SCRC.Symbolics.COM>
It was suprising to me how much controversy there was on this.
Moon thinks the basic disagreement is that some people (JonL) think that
the hash nature of tables should be explicitly exposed and other people
(Moon) think it should be hidden; consider a fixnum value for
:rehash-threshold, which interacts with the value of :size, according
to JonL.
This issue was deferred to the next meeting on a 13-2 vote.
∂04-Apr-89 1149 CL-Cleanup-mailer Issue: IN-PACKAGE-FUNCTIONALITY
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 4 Apr 89 11:48:54 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 571162; Tue 4-Apr-89 14:48:52 EDT
Date: Tue, 4 Apr 89 14:48 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: IN-PACKAGE-FUNCTIONALITY
To: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <890404144827.5.KMP@BOBOLINK.SCRC.Symbolics.COM>
From my notes...
On Tuesday, we took a straw poll.
0 opposed both proposals.
15 liked NEW-MACRO.
7 liked SELECT-ONLY.
``Keeping IN-PACKAGE makes no difference to compatibility.'' --Moon
Pitman moved to amend this to say "deprecate" instead of remove.
The motion to amend failed 3-N.
The NEW-MACRO proposal passed unamended 12-4.
On Thursday, Aaron Larson and JonL asked that the issue be reconsidered.
The motion to reconsider passed N-1.
There was a motion to rename the SELECT-PACKAGE which we'd voted in to
IN-PACKAGE -- so that the compatible syntax (IN-PACKAGE "FOO") would work
in CLtL and ANSI CL.
Steele requested verbal clarification that we were not trying to solve
the ``dusty file'' problem but rather to make it possible to write new code
that worked in old and new situations -- it was agreed that this was a
correct characterization of the proposal.
JonL's amendment passed 13-1.
Then the amended proposal was voted in 14-0.
The net effect is that NEW-MACRO passed with the name of SELECT-PACKAGE
changed to IN-PACKAGE.
∂04-Apr-89 1153 CL-Cleanup-mailer Issue: IN-SYNTAX
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 4 Apr 89 11:53:13 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 571174; Tue 4-Apr-89 14:53:10 EDT
Date: Tue, 4 Apr 89 14:52 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: IN-SYNTAX
To: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <890404145245.6.KMP@BOBOLINK.SCRC.Symbolics.COM>
Version 2, which makes LOAD and *COMPILE-FILE* bind *READTABLE* (and
which does -not- introduce the IN-SYNTAX macro mentioned in version 1)
passed 12-0-3. This version was distributed by KMP in handwritten form.
The full text of the hand-written proposal was:
Issue IN-SYNTAX (Version 2) KMP 3/30/89
Proposal (IN-SYNTAX:MINIMAL):
Define that COMPILE-FILE and LOAD bind *READTABLE* to its
current value.
Rationale:
This allows portable programs to do
(IN-PACKAGE "FOO")
(EVAL-WHEN (EVAL LOAD COMPILE)
(SETQ *READTABLE* FOO:MY-READTABLE))
at the top of a file without globally side-effecting the
environment.
Currently, there is no portable way to change the syntax only for
the duration of a file, which in turn makes customized syntax
difficult to use safely.
∂04-Apr-89 1156 CL-Cleanup-mailer Issue: LISP-PACKAGE-NAME
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 4 Apr 89 11:56:22 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 571175; Tue 4-Apr-89 14:56:13 EDT
Date: Tue, 4 Apr 89 14:55 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: LISP-PACKAGE-NAME
To: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <890404145549.7.KMP@BOBOLINK.SCRC.Symbolics.COM>
My notes say...
Steele suggested amending this to rename package USER to COMMON-LISP-USER.
The amendment was accepted as a friendly amendment.
The proposal was passed 12-4.
Barry Margolin wanted the package COMMON-LISP-USER to have nickname CL-USER.
Amendment accepted (after the original proposal was approved) 11-0-n.
The net effect is that this passed with amendment to rename package USER to
COMMON-LISP-USER with nickname CL-USER.
∂04-Apr-89 1200 CL-Cleanup-mailer Issue: LISP-SYMBOL-REDEFINITION
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 4 Apr 89 11:59:22 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 571187; Tue 4-Apr-89 14:59:17 EDT
Date: Tue, 4 Apr 89 14:58 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: LISP-SYMBOL-REDEFINITION
To: CL-Cleanup@SAIL.Stanford.EDU
cc: sandra%defun@SAIL.Stanford.EDU
Message-ID: <890404145850.8.KMP@BOBOLINK.SCRC.Symbolics.COM>
I need some help here. My notes say:
GZ wanted an amendment to strike item 8 from this list.
Sandra had some concern about the penultimate paragraph where she wanted a
prohibition on the ability to trace local functions (in implementations that
permit that). Moon thinks the proposal was amended to explicitly allow
tracing of such local function bindings.
>> Sandra: Please resolve this!
We went round in circles about item 8. A straw poll to send this back for
more work failed 6-10, so we kept on.
A motion was made to terminate discussion. This passed by 2/3 vote.
Moon's notes say item 8 may need further refinement, as for instance by GLS's
amendment. The goal is to separate properties into the ones the user can
bash and the ones the user cannot bash. [Anyway, we should expect that item 8
may come up in some form at the next meeting.]
Ultimately, I have written in my notes that we voted on
``proposal replaced by RPG, item 8 struck, w/ Sandra's prohibition
to trace local functions''
and that it passed 14-3.
>> This might not be accurate depending on how the discrepancy above is resolved.
∂04-Apr-89 1206 CL-Cleanup-mailer Issue: LOAD-OBJECTS (Version 4)
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 4 Apr 89 12:06:42 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 571193; Tue 4-Apr-89 15:06:37 EDT
Date: Tue, 4 Apr 89 15:06 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: LOAD-OBJECTS (Version 4)
To: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <890404150611.0.KMP@BOBOLINK.SCRC.Symbolics.COM>
Moon proposed friendly amendment to use the name MAKE-LOAD-FORM-SAVING-SLOTS.
The amended proposal passed 18-0.
I had to produce a revised writeup for my own purposes anyway, so it's
attached below.
-----
Issue: LOAD-OBJECTS
References: none
Related issues: LOAD-TIME-EVAL,
CONSTANT-COMPILABLE-TYPES,
CONSTANT-CIRCULAR-COMPILATION
Category: ADDITION
Forum: Cleanup
Edit history: Version 1, 2-Jan-89, by Moon (for discussion)
Version 2, 13-Jan-89, by Moon (draft updated from discussion)
Version 3, 9-Mar-89, by Moon (changes suggested by discussion)
Version 4, 4-Apr-89, by Pitman (changes per X3J13 Mar 89;
MAKE-LOAD-FORM-USING-SLOTS => MAKE-LOAD-FORM-SAVING-SLOTS)
Status: Accepted by an 18-0 vote, March 1989.
Problem description:
Common Lisp doesn't provide any way to use an object of a user-defined
type (defined with DEFCLASS or DEFSTRUCT) as a constant in a program
compiled with COMPILE-FILE. The problem is that LOAD has to be able
to "reconstruct" an equivalent object when the compiled-code file is
loaded, but the programmer has no way to tell LOAD how to do that.
Proposal (LOAD-OBJECTS:MAKE-LOAD-FORM):
Define a new generic function named MAKE-LOAD-FORM, which takes one
argument and returns two values. The argument is an object that is
referenced as a constant or as a self-evaluating form in a file being
compiled by COMPILE-FILE. The objective is to enable LOAD to
construct an equivalent object.
The first value, called the "creation form," is a form that, when
evaluated at load time, should return an object that is equivalent to
the argument. The exact meaning of "equivalent" depends on the type
of object and is up to the programmer who defines a method for
MAKE-LOAD-FORM. This is the same type of equivalence discussed
in issue CONSTANT-COMPILABLE-TYPES.
The second value, called the "initialization form," is a form that,
when evaluated at load time, should perform further initialization of
the object. The value returned by the initialization form is ignored.
If the MAKE-LOAD-FORM method returns only one value, the
initialization form is NIL, which has no effect. If the object used
as the argument to MAKE-LOAD-FORM appears as a constant in the
initialization form, at load time it will be replaced by the
equivalent object constructed by the creation form; this is how the
further initialization gains access to the object.
Both the creation form and the initialization form can contain
references to objects of user-defined types (defined precisely below).
However, there must not be any circular dependencies in creation forms.
An example of a circular dependency is when the creation form for the
object X contains a reference to the object Y, and the creation form
for the object Y contains a reference to the object X. A simpler
example would be when the creation form for the object X contains
a reference to X itself. Initialization forms are not subject to
any restriction against circular dependencies, which is the entire
reason that initialization forms exist. See the example of circular
data structures below.
The creation form for an object is always evaluated before the
initialization form for that object. When either the creation form or
the initialization form references other objects of user-defined types
that have not been referenced earlier in the COMPILE-FILE, the
compiler collects all of the creation and initialization forms. Each
initialization form is evaluated as soon as possible after its
creation form, as determined by data flow. If the initialization form
for an object does not reference any other objects of user-defined
types that have not been referenced earlier in the COMPILE-FILE, the
initialization form is evaluated immediately after the creation form.
If a creation or initialization form F references other objects of
user-defined types that have not been referenced earlier in the
COMPILE-FILE, the creation forms for those other objects are evaluated
before F, and the initialization forms for those other objects are
also evaluated before F whenever they do not depend on the object
created or initialized by F. Where the above rules do not uniquely
determine an order of evaluation, which of the possible orders of
evaluation is chosen is unspecified.
While these creation and initialization forms are being evaluated, the
objects are possibly in an uninitialized state, analogous to the state
of an object between the time it has been created by ALLOCATE-INSTANCE
and it has been processed fully by INITIALIZE-INSTANCE. Programmers
writing methods for MAKE-LOAD-FORM must take care in manipulating
objects not to depend on slots that have not yet been initialized.
It is unspecified whether LOAD calls EVAL on the forms or does some
other operation that has an equivalent effect. For example, the
forms might be translated into different but equivalent forms and
then evaluated, they might be compiled and the resulting functions
called by LOAD, or they might be interpreted by a special-purpose
interpreter different from EVAL. All that is required is that the
effect be equivalent to evaluating the forms.
COMPILE-FILE calls MAKE-LOAD-FORM on any object that is referenced as
a constant or as a self-evaluating form, if the object's metaclass is
STANDARD-CLASS, STRUCTURE-CLASS, any user-defined metaclass (not a
subclass of BUILT-IN-CLASS), or any of a possibly-empty
implementation-defined list of other metaclasses. COMPILE-FILE will
only call MAKE-LOAD-FORM once for any given object (compared with EQ)
within a single file.
It is valid for user programs to call MAKE-LOAD-FORM in other
circumstances, providing the argument's metaclass is not BUILT-IN-CLASS
or a subclass of BUILT-IN-CLASS.
Define a new function named MAKE-LOAD-FORM-SAVING-SLOTS, which takes
one required argument and one optional argument and returns two
values. This can be useful in user-written MAKE-LOAD-FORM methods.
The first argument is the object. The optional second argument is a
list of the names of the slots to preserve; it defaults to all of the
local slots. MAKE-LOAD-FORM-SAVING-SLOTS returns forms that construct
an equivalent object using MAKE-INSTANCE and SETF of SLOT-VALUE for
slots with values, or SLOT-MAKUNBOUND for slots without values, or
using other functions of equivalent effect.
MAKE-LOAD-FORM-SAVING-SLOTS returns two values, thus it can deal with
circular structures. MAKE-LOAD-FORM-SAVING-SLOTS works for any object
of metaclass STANDARD-CLASS or STRUCTURE-CLASS. Whether the result is
useful in an application depends on whether the object's type and slot
contents fully capture the application's idea of the object's state.
MAKE-LOAD-FORM of an object of metaclass STANDARD-CLASS or
STRUCTURE-CLASS for which no user-defined method is applicable signals
an error. It is valid to implement this either by defining default
methods on STANDARD-OBJECT and STRUCTURE-OBJECT that signal an error
or by having no applicable method for those classes.
Examples:
;; Example 1
(defclass my-class ()
((a :initarg :a :reader my-a)
(b :initarg :b :reader my-b)
(c :accessor my-c)))
(defmethod shared-initialize ((self my-class) ignore &rest ignore)
(unless (slot-boundp self 'c)
(setf (my-c self) (some-computation (my-a self) (my-b self)))))
(defmethod make-load-form ((self my-class))
`(make-instance ',(class-name (class-of self))
:a ',(my-a self) :b ',(my-b self)))
In this example, an equivalent instance of my-class is reconstructed
by using the values of two of its slots. The value of the third slot
is derived from those two values.
Another way to write the last form in the above example would have been
(defmethod make-load-form ((self my-class))
(make-load-form-saving-slots self '(a b)))
;; Example 2
(defclass my-frob ()
((name :initarg :name :reader my-name)))
(defmethod make-load-form ((self my-frob))
`(find-my-frob ',(my-name self) :if-does-not-exist :create))
In this example, instances of my-frob are "interned" in some way.
An equivalent instance is reconstructed by using the value of the
name slot as a key for searching existing objects. In this case
the programmer has chosen to create a new object if no existing
object is found; alternatively she could have chosen to signal an
error in that case.
;; Example 3
(defclass tree-with-parent () ((parent :accessor tree-parent)
(children :initarg :children)))
(defmethod make-load-form ((x tree-with-parent))
(values
;; creation form
`(make-instance ',(class-of x) :children ',(slot-value x 'children))
;; initialization form
`(setf (tree-parent ',x) ',(slot-value x 'parent))))
In this example, the data structure to be dumped is circular, because
each parent has a list of its children and each child has a reference
back to its parent. Suppose make-load-form is called on one object in
such a structure. The creation form creates an equivalent object and
fills in the children slot, which forces creation of equivalent
objects for all of its children, grandchildren, etc. At this point
none of the parent slots have been filled in. The initialization form
fills in the parent slot, which forces creation of an equivalent
object for the parent if it was not already created. Thus the entire
tree is recreated at load time. At compile time, MAKE-LOAD-FORM is
called once for each object in the true. All of the creation forms
are evaluated, in unspecified order, and then all of the
initialization forms are evaluated, also in unspecified order.
;; Example 4
(defstruct my-struct a b c)
(defmethod make-load-form ((s my-struct))
(make-load-form-saving-slots s))
In this example, the data structure to be dumped has no special
properties and an equivalent structure can be reconstructed
simply by reconstructing the slots' contents.
Rationale:
Only the programmer who designed a class can know the correct
way to reconstruct objects of that class at load time, therefore
the reconstruction should be controlled by a generic function.
Using EVAL as the interface for telling LOAD what to do provides
full generality.
MAKE-LOAD-FORM returns two values so that circular structures can
be handled. If CONSTANT-CIRCULAR-COMPILATION is rejected,
MAKE-LOAD-FORM will only return one value, although implementations
that make an extension to support circular constants will probably
also make the extension to accept two values from MAKE-LOAD-FORM.
The default for class objects and structures is to signal an error,
rather than picking some particular object reconstruction technique,
because no reconstruction technique is appropriate for all objects.
It only takes two lines of code, as in example 4, to instruct the
compiler to use the technique that most often has been suggested
as the default.
MAKE-LOAD-FORM has a natural resemblance to PRINT-OBJECT, as a hook
for the programmer to control the system's actions.
The order of evaluation rules for creation and initialization forms
eliminate the possibility of partially initialized objects in the
absence of circular structures, and reduce it to the minimum possible
in the presence of circular structures. This allows nodes in
non-circular structures to be built out of fully initialized subparts.
Current practice:
Symbolics Flavors has something like this, but under a different name.
The name Symbolics uses is not suitable for standardization.
JonL reports that Lucid is getting more and more requests for this.
Cost to Implementors:
This seems like only a few one-line changes in the compiled-code
file writer and reader. MAKE-LOAD-FORM-SAVING-SLOTS is a couple
dozen lines of code, assuming the presence of the CLOS metaobject
protocol or an implementation-dependent equivalent.
Cost to Users:
None.
Cost of non-adoption:
Serious impairment of the ability to use extended-type objects. Each
implementation will probably make up its own version of this as an
extension.
Performance impact:
None.
Benefits:
See Cost of non-adoption.
Esthetics:
No significant positive or negative impact.
Discussion:
It would be possible to define an additional level of protocol that
allows multiple classes to contribute to the reconstruction of an
object, combining initialization arguments contributed by each class.
Since a user can easily define that in terms of MAKE-LOAD-FORM without
modifying the Lisp system, it is not being proposed now.
Any type that has a read syntax is likely to appear as a quoted
constant or inside a quoted constant. Pathnames are one example, user
programs often define others. Also many implementations provide a way
to create a compiled-code file full of data (rather than compiled Lisp
programs), and such data probably include extended-type objects.
Moon supports this. David Gray and John Rose made major contributions
to the discussion that produced this improved version 2 proposal.
∂04-Apr-89 1217 CL-Cleanup-mailer Issue: LOAD-TRUENAME
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 4 Apr 89 12:17:37 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 571207; Tue 4-Apr-89 15:17:27 EDT
Date: Tue, 4 Apr 89 15:17 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: LOAD-TRUENAME
To: CL-Cleanup@SAIL.Stanford.EDU
cc: Loeffler@MCC.Com
Message-ID: <890404151703.2.KMP@BOBOLINK.SCRC.Symbolics.COM>
My notes say that Moon wanted some other variables. I wrote this up as
an amendment, but neither the amendment nor the proposal was ever voted on.
Moon mailed out a version 2 but then withdrew it in favor of my amendment.
The text of my amendment was:
Proposed amendment to LOAD-TRUENAME KMP 3/30/89
Also introduce new variables:
*LOAD-PATHNAME*
This special variable is initially NIL but is bound by LOAD
to hold a pathname which represents the filename given as the
first argument to LOAD. That is, (PATHNAME arg1).
*COMPILE-FILE-PATHNAME*
This special variable is initially NIL but is bound by COMPILE-FILE
to hold a pathname which represents the filename given as the
first argument to COMPILE-FILE. That is, (PATHNAME arg1).
Rationale:
The truename may be useful to tell the real file being loaded,
but sometimes information about the link names or logical devices
traversed is important, too.
Note that these new variables alone are not adequate since
TRUENAME on these pathnames might not yield the value of the
-TRUENAME* variables if the file has been deleted or protected
since the open occurred (in some implementations).
The problem is whether the values of the -pathname variables is the
original argument or the merged, defaulted value. Moon thinks it
should be the latter. I think there are arguments for either
one, but also think that this sub-issue is "in the noise" and
should not hold up progress. Loeffler volunteered to work on this.
By a 14-1 vote, we deferred this to the next meeting.
∂04-Apr-89 1219 CL-Cleanup-mailer Issue: LOCALLY-TOP-LEVEL
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 4 Apr 89 12:19:22 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 571209; Tue 4-Apr-89 15:19:16 EDT
Date: Tue, 4 Apr 89 15:18 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: LOCALLY-TOP-LEVEL
To: CL-Cleanup@SAIL.Stanford.EDU
cc: Dick@Wheaties.AI.MIT.EDU
Message-ID: <890404151849.3.KMP@BOBOLINK.SCRC.Symbolics.COM>
[Waters added for sake of amusing story at end.]
My notes say this passed unanimously.
I also noted that this took 15 seconds to vote in. In fact, we did it
while in the middle of PRETTY-PRINT-INTERFACE sort of at ``interrupt level''
in a way that confused Mary's taking of the minutes and we -almost- got
the pretty printer marked as voted in because she didn't realize we'd
shifted topics.
∂04-Apr-89 1219 CL-Cleanup-mailer Issue: LOOP-AND-DISCREPANCY
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 4 Apr 89 12:19:40 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 571210; Tue 4-Apr-89 15:19:35 EDT
Date: Tue, 4 Apr 89 15:19 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: LOOP-AND-DISCREPANCY
To: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <890404151910.4.KMP@BOBOLINK.SCRC.Symbolics.COM>
My notes say this passed 14-0.
∂04-Apr-89 1221 CL-Cleanup-mailer Issue: MACRO-ENVIRONMENT-EXTENT
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 4 Apr 89 12:21:23 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 571211; Tue 4-Apr-89 15:21:17 EDT
Date: Tue, 4 Apr 89 15:20 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: MACRO-ENVIRONMENT-EXTENT
To: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <890404152045.5.KMP@BOBOLINK.SCRC.Symbolics.COM>
My notes say...
Gregor says "the cartel" thinks CLOS is unaffected by this proposal.
In a straw poll, we checked which option people favor.
11 DYNAMIC
7 `not DYNAMIC'
It later became clear that some people thought DYNAMIC-WITH-COPIER
was in the `not DYNAMIC' set.
In spite of the confusion, option DYNAMIC passed 15-1.
A motion to replace option DYNAMIC with option DYNAMIC-WITH-COPIER
failed 1-12.
∂04-Apr-89 1221 CL-Cleanup-mailer Issue: MAKE-STRING-FILL-POINTER
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 4 Apr 89 12:21:38 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 571212; Tue 4-Apr-89 15:21:32 EDT
Date: Tue, 4 Apr 89 15:21 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: MAKE-STRING-FILL-POINTER
To: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <890404152107.6.KMP@BOBOLINK.SCRC.Symbolics.COM>
Someone (GZ?) objected that this would change the result type from MAKE-STRING
from being a simple-string, and would break type inferencing code.
It was agreed that this should be withdrawn.
∂04-Apr-89 1222 CL-Cleanup-mailer Issue: PACKAGE-FUNCTION-CONSISTENCY
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 4 Apr 89 12:22:38 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 571216; Tue 4-Apr-89 15:22:10 EDT
Date: Tue, 4 Apr 89 15:21 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: PACKAGE-FUNCTION-CONSISTENCY
To: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <890404152140.7.KMP@BOBOLINK.SCRC.Symbolics.COM>
This was on the agenda but not discussed.
Since it is just a clarification, I assume it could still come
up at the next meeting.
∂04-Apr-89 1226 CL-Cleanup-mailer Issue: PATHNAME-LOGICAL
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 4 Apr 89 12:25:09 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 571228; Tue 4-Apr-89 15:25:06 EDT
Date: Tue, 4 Apr 89 15:24 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: PATHNAME-LOGICAL
To: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <890404152441.1.KMP@BOBOLINK.SCRC.Symbolics.COM>
This was deferred to the next meeting.
Moon says that Masinter "tried manfully" to encourage him to write up a
proposal, but I doubt anyone really expects it to happen.
∂04-Apr-89 1227 CL-Cleanup-mailer Issue: PATHNAME-PRINT-READ
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 4 Apr 89 12:27:19 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 571237; Tue 4-Apr-89 15:27:19 EDT
Date: Tue, 4 Apr 89 15:26 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: PATHNAME-PRINT-READ
To: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <890404152654.2.KMP@BOBOLINK.SCRC.Symbolics.COM>
This was deferred from Tuesday to Thursday but then didn't come
around for discussion due to lack of time.
I guess I think it's possible that this could still come up at
the next meeting since it can at least be argued to be a clarification.
Others might disagree though.
∂04-Apr-89 1227 CL-Cleanup-mailer Issue: PATHNAME-CANONICAL-TYPE
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 4 Apr 89 12:23:18 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 571220; Tue 4-Apr-89 15:23:07 EDT
Date: Tue, 4 Apr 89 15:22 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: PATHNAME-CANONICAL-TYPE
To: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <890404152241.8.KMP@BOBOLINK.SCRC.Symbolics.COM>
This was identified as `medium' importance in the pathname world
and deferred to the next meeting.
∂04-Apr-89 1231 CL-Cleanup-mailer Issue: PATHNAME-SUBDIRECTORY-LIST
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 4 Apr 89 12:28:56 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 571239; Tue 4-Apr-89 15:28:55 EDT
Date: Tue, 4 Apr 89 15:28 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: PATHNAME-SUBDIRECTORY-LIST
To: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <890404152831.3.KMP@BOBOLINK.SCRC.Symbolics.COM>
This was identified as `important' and deferred to the
next meeting.
∂04-Apr-89 1232 CL-Cleanup-mailer Issue: PEEK-CHAR-READ-CHAR-ECHO
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 4 Apr 89 12:31:23 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 571244; Tue 4-Apr-89 15:31:19 EDT
Date: Tue, 4 Apr 89 15:30 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: PEEK-CHAR-READ-CHAR-ECHO
To: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <890404153055.6.KMP@BOBOLINK.SCRC.Symbolics.COM>
Kim Barrett mentioned again that he wants to reopen this, but nothing
was done at this meeting.
∂04-Apr-89 1233 CL-Cleanup-mailer Issue: PRETTY-PRINT-INTERFACE
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 4 Apr 89 12:31:42 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 571245; Tue 4-Apr-89 15:31:40 EDT
Date: Tue, 4 Apr 89 15:31 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: PRETTY-PRINT-INTERFACE
To: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <890404153114.7.KMP@BOBOLINK.SCRC.Symbolics.COM>
My notes say this was deferred to the next meeting by a vote of N-2.
∂04-Apr-89 1235 CL-Cleanup-mailer Issue: PATHNAME-COMPONENT-CASE
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 4 Apr 89 12:24:06 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 571225; Tue 4-Apr-89 15:23:56 EDT
Date: Tue, 4 Apr 89 15:23 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: PATHNAME-COMPONENT-CASE
To: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <890404152331.9.KMP@BOBOLINK.SCRC.Symbolics.COM>
This was identified as `important' and deferred to
the next meeting (with explicit exception to cut-off
date on 18-0 vote).
∂04-Apr-89 1238 CL-Cleanup-mailer Issue: PROCLAIM-LEXICAL
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 4 Apr 89 12:36:44 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 571257; Tue 4-Apr-89 15:36:39 EDT
Date: Tue, 4 Apr 89 15:36 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: PROCLAIM-LEXICAL
To: CL-Cleanup@SAIL.Stanford.EDU
cc: JAR@AI.AI.MIT.EDU
Message-ID: <890404153614.0.KMP@BOBOLINK.SCRC.Symbolics.COM>
My notes say...
KMP made a friendly amendment to clarify the status of undeclared
free variables (as undefined). The text of the amendment was:
-----
Proposed amendment to PROCLAIM-LEXICAL KMP 3/30/89
Add: Referencing a free variable that is neither proclaimed
nor declared LEXICAL nor SPECIAL has undefined
consequences.
Rationale:
This enables existing implementations to persist in permitting,
for example,
(SETQ X 3)
without defining X as lexical or special, yet allows those
implementations that want to warn about
(DEFUN F (X) (+ X Y))
when Y is undeclared/proclaimed to legitimately do so.
-----
GZ wanted an amendment that would make it an error to use the LEXICAL
declaration when there was not a lexically visible binding to which
it might refer. Her amendment failed 5-12.
The proposal (with friendly amendment by KMP but without GZ's
amendment) finally failed 6-11.
∂04-Apr-89 1238 CL-Cleanup-mailer Issue: READ-CASE-SENSITIVITY
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 4 Apr 89 12:38:11 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 571263; Tue 4-Apr-89 15:37:46 EDT
Date: Tue, 4 Apr 89 15:37 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: READ-CASE-SENSITIVITY
To: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <890404153716.1.KMP@BOBOLINK.SCRC.Symbolics.COM>
This was deferred to the next meeting by a 13-3 vote.
The drafters were requested to present only a single alternative.
∂04-Apr-89 1240 CL-Cleanup-mailer Issue: READ-DELIMITED-LIST-EOF
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 4 Apr 89 12:38:46 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 571265; Tue 4-Apr-89 15:38:36 EDT
Date: Tue, 4 Apr 89 15:38 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: READ-DELIMITED-LIST-EOF
To: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <890404153809.2.KMP@BOBOLINK.SCRC.Symbolics.COM>
This issue was mentioned but was not on my list of possible topics.
No action was taken.
Since it's probably a clarification (?) and I assume it might still
come up later.
∂04-Apr-89 1242 CL-Cleanup-mailer Issue: REMF-DESTRUCTION-UNSPECIFIED (Version 6)
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 4 Apr 89 12:41:09 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 571273; Tue 4-Apr-89 15:41:04 EDT
Date: Tue, 4 Apr 89 15:40 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: REMF-DESTRUCTION-UNSPECIFIED (Version 6)
To: CL-Cleanup@SAIL.Stanford.EDU
cc: DLA@JASPER.SCRC.Symbolics.COM
Message-ID: <890404154038.4.KMP@BOBOLINK.SCRC.Symbolics.COM>
My notes say I suggested friendly amendments to change "VREF" to "AREF"
and "it none" to "none" in the NSUBSTITUTE-xxx part.
Then the amended proposal was passed 16-1.
∂04-Apr-89 1244 CL-Cleanup-mailer Issue: PATHNAME-COMPONENT-VALUE
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 4 Apr 89 12:24:23 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 571227; Tue 4-Apr-89 15:24:18 EDT
Date: Tue, 4 Apr 89 15:23 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: PATHNAME-COMPONENT-VALUE
To: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <890404152354.0.KMP@BOBOLINK.SCRC.Symbolics.COM>
This was deferred to the next meeting.
∂04-Apr-89 1244 CL-Cleanup-mailer Issue: SETF-MULTIPLE-STORE-VARIABLES
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 4 Apr 89 12:44:43 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 571286; Tue 4-Apr-89 15:44:42 EDT
Date: Tue, 4 Apr 89 15:44 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: SETF-MULTIPLE-STORE-VARIABLES
To: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <890404154416.6.KMP@BOBOLINK.SCRC.Symbolics.COM>
This was on the agenda but never gotten to.
I think it might come up at the next meeting since it's mostly just a clarification.
∂04-Apr-89 1249 CL-Cleanup-mailer Issue: SYMBOL-MACROLET-SEMANTICS
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 4 Apr 89 12:45:39 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 571287; 4 Apr 89 15:45:32 EDT
Date: Tue, 4 Apr 89 15:45 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: SYMBOL-MACROLET-SEMANTICS
To: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <890404154506.7.KMP@BOBOLINK.SCRC.Symbolics.COM>
My notes say...
People wanted PSETQ added with SETQ in the list of things SYMBOL-MACROLET
hacks specially.
RWK wants changes to deal with *MACRO-EXPANSION-HOOK* to clarify how it gets
called when PSETQ and SETQ are used. He seemed to want it called with the
SETF expander and a consed-up SETF form. I'd rather it be called with a special
magic expander and the actual SETQ form.
RPG wants to flush SYMBOL-MACROLET altogether and have people just use
WITH-SLOTS. Many people didn't want to give up the flexibility of
SYMBOL-MACROLET.
A vote on Version 6 "as is" passed 16-2.
A straw poll was taken on the question ``should we ask RPG to draft a proposal
for flushing SYMBOL-MACROLET.'' On a 6-8 vote, we opted not to write such
a proposal. [That doesn't preclude him from doing it anyway, of course.]
∂04-Apr-89 1249 CL-Cleanup-mailer Issue: THE-AMBIGUITY
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 4 Apr 89 12:46:09 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 571288; Tue 4-Apr-89 15:46:07 EDT
Date: Tue, 4 Apr 89 15:45 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: THE-AMBIGUITY
To: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <890404154542.8.KMP@BOBOLINK.SCRC.Symbolics.COM>
This was on the agenda but didn't come up.
Being a clarification, I assume it might come up next meeting.
∂04-Apr-89 1252 CL-Cleanup-mailer Issue: TIME-ZONE-NON-INTEGER
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 4 Apr 89 12:46:43 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 571290; Tue 4-Apr-89 15:46:41 EDT
Date: Tue, 4 Apr 89 15:46 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: TIME-ZONE-NON-INTEGER
To: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <890404154616.9.KMP@BOBOLINK.SCRC.Symbolics.COM>
My notes say...
We managed to waste lots of valuable time on this.
Haflich seemed to want to use incredibly large negative time zones in
order to reason about the first century A.D. or some such thing. He
asked ``Can I make the time zone be most-positive-bignum*5?'' JonL
responded ``most-positive-bignum--my favorite number!''
Moon proposed time zones be multiples of 1/3600 so that they were
even numbers of seconds. (Some people suspected this was a subtle
marketing ploy for Symbolics.) This amendment was accepted 11-0.
Pitman proposed that we limit time zone to the range [-24,24], inclusive.
The inclusive was to allow countries to disagree on which end was open,
since it was agreed that the correct value here is a largely political,
rather than technical issue. The amendment was accepted 8-5.
The full proposal with both amendments passed 18-0.
∂04-Apr-89 1253 CL-Cleanup-mailer Issue: PATHNAME-SYNTAX-ERROR-TIME
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 4 Apr 89 12:29:16 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 571240; Tue 4-Apr-89 15:29:14 EDT
Date: Tue, 4 Apr 89 15:28 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: PATHNAME-SYNTAX-ERROR-TIME
To: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <890404152844.4.KMP@BOBOLINK.SCRC.Symbolics.COM>
This was deferred to the next meeting.
∂04-Apr-89 1256 CL-Cleanup-mailer Issue: PATHNAME-WILD
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 4 Apr 89 12:29:31 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 571241; Tue 4-Apr-89 15:29:26 EDT
Date: Tue, 4 Apr 89 15:29 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: PATHNAME-WILD
To: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <890404152902.5.KMP@BOBOLINK.SCRC.Symbolics.COM>
This was deferred to the next meeting.
∂04-Apr-89 1258 CL-Cleanup-mailer Issue: WITH-COMPILATION-UNIT
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 4 Apr 89 12:49:03 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 571301; Tue 4-Apr-89 15:48:50 EDT
Date: Tue, 4 Apr 89 15:48 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: WITH-COMPILATION-UNIT
To: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <890404154825.2.KMP@BOBOLINK.SCRC.Symbolics.COM>
My notes say...
Users wanting to write a portable DEFSYSTEM want this.
This passed 11-6 with an amendment to say it defers "warnings" rather
than "actions" and with an amendment to say it does not apply to the
COMPILE function (only to COMPILE-FILE).
∂04-Apr-89 1301 CL-Cleanup-mailer Issue: PRINT-CASE-PRINT-ESCAPE-INTERACTION
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 4 Apr 89 12:32:04 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 571246; 4 Apr 89 15:32:01 EDT
Date: Tue, 4 Apr 89 15:31 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: PRINT-CASE-PRINT-ESCAPE-INTERACTION
To: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <890404153136.8.KMP@BOBOLINK.SCRC.Symbolics.COM>
My notes say this was deferred from Tuesday to Thursday but then didn't
come up for discussion.
Being a clarification, I expect it to come up at the next meeting.
∂04-Apr-89 1301 CL-Cleanup-mailer Issue: EXIT-EXTENT (version 7)
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 4 Apr 89 13:01:17 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 571323; Tue 4-Apr-89 16:01:09 EDT
Date: Tue, 4 Apr 89 16:00 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: EXIT-EXTENT (version 7)
To: CL-Cleanup@sail.stanford.edu
Message-ID: <19890404200056.5.MOON@EUPHRATES.SCRC.Symbolics.COM>
This contains the amendments that were voted in at the X3J13 meeting last week.
I also edited the rationale and the examples to make them consistent with the
amended proposal. The MINIMAL proposal here passed 11-5.
Issue: EXIT-EXTENT
References: CATCH, THROW (p 142),
BLOCK, RETURN, RETURN-FROM,
TAGBODY, GO, UNWIND-PROTECT,
Dynamic extent (CLtL p.37),
Nested dynamic extents (CLtL p.38),
Blocks can only be exited once (CLtL p.120),
Catch is disestablished just before the values
are returned (CLtL p.139).
Related issues: UNWIND-PROTECT-NON-LOCAL-EXIT is superseded
by this one.
Category: CLARIFICATION
Edit history: ... Version 5 of UNWIND-PROTECT-NON-LOCAL-EXIT, 23-May-88 ...
Version 1, 5-Sep-88, by Moon, for discussion
Version 2, 1-Oct-88, by Masinter, minor edits
Version 3, 7-Oct-88, by Moon, wording improvements
Version 4, 7-Dec-88, by Masinter, add MEDIUM from
UNWIND-PROTECT-NON-LOCAL-EXIT, discussion.
Version 5, 12-Dec-88, Masinter, clarify MINIMAL allows MEDIUM
Version 6, 8-Jan-89, Masinter, fix some bugs
Version 7, 4-Apr-89, Moon, amend per X3J13 Mar-89, and make
rationale and examples consistent with that
Problem description:
CLtL does not specify precisely when the dynamic extent (lifetime)
of a nonlocal exit such as a CATCH, BLOCK, or TAGBODY ends.
For example, at what point is it no longer possible to RETURN-FROM
a particular BLOCK?
An "exit" refers to a point from which control can be transferred.
For a THROW or RETURN-FROM, the "exit" is the corresponding CATCH
or BLOCK body. For a GO, the "exit" is the form within the TAGBODY
which was being executed at the time the GO is performed.
The extent of an exit is dynamic; it is not indefinite. The extent
of an exit begins when the corresponding form (CATCH, BLOCK or TAGBODY
clause) is entered. When the extent of an exit has ended, it is no
longer legal to return from it.
The extent of an exit is not the same thing as the scope of the
designator by which the exit is identified. For example, a BLOCK
name has lexical scope but the extent of its exit is dynamic; the
scope of a CATCH tag could differ from the extent of the CATCH's
return point. (That's part of what is at issue here.)
The ambiguity at issue arises for the case where there are transfers
of control from the cleanup clauses of an UNWIND-PROTECT.
When a transfer of control is initiated by GO, RETURN-FROM or THROW,
a variety of events occur before the transfer of control is complete.
In particular,
(a) the cleanup clauses of any intervening UNWIND-PROTECT clauses
are evaluated,
(b) intervening dynamic bindings of special variables and catch tags
are undone,
(c) intervening exits are "abandoned", i.e., their extent ends and it
is no longer legal to attempt to transfer control through them,
(d) the extent of the exit being invoked ends,
(e) control is finally passed to the target.
The order of these events is not explicit in CLtL, however. The
implementation note on p.142 gives a clue about the interweaving
of (a) and (b), but there are differing opinions about the times
at which (c) and (d) may occur. In particular,
Is it legal for an implementation to end the extent of all
intervening exits before processing the cleanup clauses of intervening
UNWIND-PROTECTs?
What is the dynamic context at the time UNWIND-PROTECT clauses are
evaluated: how is the unwinding of dynamic bindings intertwined with
evaluation of UNWIND-PROTECT cleanup clauses?
Proposal (EXIT-EXTENT:MINIMAL):
The extent of an exit being "abandoned" because it is being passed over
ends as soon as the transfer of control is initiated. That is, the
event (c) occurs at the beginning of the initiation of the transfer of
control. In the language of the implementation note on p.142, the
extent ends at the beginning of the second pass. It is an error to
attempt a transfer of control to an exit whose dynamic extent has
ended.
The event (d) occurs at the end of the transfer of control.
Otherwise, events (a) and (b)--the undoing of dynamic binding of special
variables and CATCH tags, and the execution of UNWIND-PROTECT cleanup
clauses--are performed in the order corresponding to the reverse order
in which they were established, as implied by the implementation note
on p.142. The effect of this is that the cleanup clauses of an UNWIND-PROTECT
will see the same dynamic bindings of variables and CATCH tags as were
visible when the UNWIND-PROTECT was entered.
This proposal is called "minimal" because it gives exits the smallest
extent consistent with CLtL, except that event (d) occurs later than
CLtL requires. A program that presumed a longer extent would be in
error. Implementations may support longer extents for exits than is
required by this proposal; in particular, an implementation which
allowed the larger extent of the MEDIUM proposal below would still
conform.
Proposal (EXIT-EXTENT:MEDIUM):
The events of (a), (b), (c) and (d) are interwoven in the reverse
order in which they were established. In particular, the extent of
a passed-over exit ends when control reaches a frame that was
established before the exit was established.
In particular, it is legal, during the evaluation of an UNWIND-PROTECT
cleanup form executed because of a non-local transfer of control, to
initiate a new transfer of control to an exit intervening between the
UNWIND-PROTECT and the original target; the original processing of
transfer of control is abandoned.
Examples:
;; Error under either proposal: BLOCK exits normally before RETURN
(funcall (block nil #'(lambda () (return))))
;; Error under either proposal: normal exit before GO
(let ((a nil))
(tagbody t (setq a #'(lambda () (go t))))
(funcall a))
;; Error under either proposal: TAGBODY is passed over, before GO
(funcall (block nil
(tagbody a (return #'(lambda () (go a))))))
;;returns 2 under MEDIUM and MINIMAL, was error under MINIMAL version 6
(block nil
(unwind-protect (return 1)
(return 2)))
;;returns 2 under MEDIUM, is error under MINIMAL
(block a
(block b
(unwind-protect (return-from a 1)
(return-from b 2))))
;; returns 2 under MEDIUM and MINIMAL, was error under MINIMAL version 6
(catch nil
(unwind-protect (throw nil 1)
(throw nil 2)))
;; returns 2 under MEDIUM, is error under MINIMAL
;; because the catch of B is passed over by
;; the first THROW, hence portable programs must assume its dynamic extent
;; is terminated. The binding of the catch tag is not yet disestablished
;; and therefore it is the target of the second throw.
(catch 'a
(catch 'b
(unwind-protect (throw 'a 1)
(throw 'b 2))))
;; the following was an error under MINIMAL version 6; the extent of
;; the inner catch terminates as soon as the THROW commences, even
;; though it remains in scope. Thus, the THROW of :SECOND-THROW
;; sees the inner CATCH, but its extent has ended.
;; under MEDIUM and MINIMAL version 7,
;; it prints "The inner catch returns :SECOND-THROW"
;; and then returns :OUTER-CATCH.
(catch 'foo
(format t "The inner catch returns ~s.~%"
(catch 'foo
(unwind-protect (throw 'foo :first-throw)
(throw 'foo :second-throw))))
:outer-catch))
;; Following returns 10 under either proposal. The inner
;; CATCH of A is passed over, but because that CATCH
;; is disestablished before the THROW to A is executed,
;; it isn't seen.
(catch 'a
(catch 'b
(unwind-protect (1+ (catch 'a (throw 'b 1)))
(throw 'a 10))))
;; Following is an error under MINIMAL because the extent of
;; the (CATCH 'BAR ...) exit ends when the (THROW 'FOO ...)
;; commences.
;; Under MEDIUM, the pending exit to tag FOO is discarded by the
;; second THROW to BAR and the value 4 is transferred to
;; (CATCH 'BAR ...), which returns 4. The (CATCH 'FOO ...)
;; then returns the 4 because its first argument has returned
;; normally. XXX is not printed.
(CATCH 'FOO
(CATCH 'BAR
(UNWIND-PROTECT (THROW 'FOO 3)
(THROW 'BAR 4)
(PRINT 'XXX))))
;; Following returns 4 under either proposal; XXX is not printed.
;; The (THROW 'FOO ...) has no effect on the scope of the BAR
;; catch tag or the extent of the (CATCH 'BAR ...) exit.
(CATCH 'BAR
(CATCH 'FOO
(UNWIND-PROTECT (THROW 'FOO 3)
(THROW 'BAR 4)
(PRINT 'XXX))))
;;The following are legal and print 5 under either proposal:
(block nil
(let ((x 5))
(declare (special x))
(unwind-protect (return)
(print x))))
(block nil
(let ((x 5))
(declare (special x))
(unwind-protect
(if (test) (return))
(print x))))
Rationale:
For MINIMAL: Giving exits the smallest extent consistent with CLtL
maximizes freedom for implementations; there are few applications,
if any, that require a longer extent. Delaying event (d) until
the transfer of control is completed allows multiple attempts to
exit from a single exit, if the first attempt is interrupted,
possibly by an error.
For MEDIUM: Giving exits a longer extent has cleaner semantics.
Current practice:
Both implementations of Symbolics Genera (3600 and Ivory) end the extent
of a target BLOCK or CATCH at the moment the values are returned, and
end the extent of a passed-over exit at the moment the THROW, RETURN, or
GO commences. This choice of extent maximizes efficiency within the
particular stack structure used by these implementations, by avoiding
the need to retain the control information needed to use a passed over
exit through the transfer of control. Genera signals an error if an
attempt is made to use an exit that has been passed over.
In some implementations, it is possible for a throw or non-local exit
to be effectively "stopped" by an UNWIND-PROTECT cleanup clause that
performs a non-local transfer of control to a passed-over exit.
Some implementations crash or otherwise generate garbage code for
non-local exits from cleanup clauses of UNWIND-PROTECT.
Cost to Implementors:
No currently valid implementation will be made invalid by the MINIMAL
proposal. Some implementors may wish to add error checks if they
do not already have them.
MEDIUM would have a high cost for those implementations that currently
have shorter extent.
Cost to Users:
Most user programs don't do this, so there is likely little cost
of converting existing code in any case. In any case, current implementations
differ enough that this issue ostensibly does not
affect current portable programs. Some users might have code that
relies on the "unstoppable loops" that can be created with the MEDIUM
proposal.
Benefits:
Either proposal would make Common Lisp more precisely defined.
Cost of non-adoption :
The semantics of exits will remain ambiguous.
Esthetics:
Precisely specifying the meaning of dynamic extent improves the language.
Leaving implementations free to implement a longer extent if they choose
can be regarded as unesthetic, but consistent with Common Lisp philosophy.
Having a CATCH that is in scope even though its extent has ended may
seem unesthetic, but it is consistent with how BLOCK behaves.
Discussion:
This issue is controversial. It was first discussed under the issue
named UNWIND-PROTECT-CLEANUP-NON-LOCAL-EXIT. The issue was recast as
the more global one of "extent of exits" rather than the specific
one of "what happens if a cleanup in an UNWIND-PROTECT does a non-
local exit", but the problem cases for both topics are the same.
The goal of the MINIMAL proposal is to clarify the ambiguity in CLtL while
minimizing changes to the current situation. The MEDIUM proposal
defines the extent of an exit to end at the last moment possible
within some particular reference implementation. It has
a cost to implementors whose implementation is not identical to the
reference implementation. Another alternative proposal, not considered
here, would duck the issue by outlawing all non-local exits from UNWIND-PROTECT
cleanup forms. That alternative would have a substantial cost to some users.
Scheme is cleaner: it avoids this issue by specifying that the extent
of an exit never ends.
An argument for the MEDIUM proposal was made based on the example:
(block foo
(block bar
(unwind-protect
(return-from foo 'foo)
(return-from bar 'bar))))
Since there is no reason for FOO and BAR not to be treated interchangeably,
calling this an error would be inappropriate.
It was argued that the MINIMAL proposal is equivalent to practically
outlawing non-local exits from UNWIND-PROTECT cleanup clauses, because
there is no general way to determine the target of the non-local exit
that caused the cleanup clause to be invoked.
The following example was offered as an argument against MINIMAL. Given:
(block nil
(handler-case
(unwind-protect (return)
(error "foo")) ;probably an error, under the proposal
(error ()
(print "foo"))))
If the ERROR handler has the same scope and extent a CATCH in the same place
would have (and that seems reasonable, though I'm not certain that the
condition system specifically requires that interpretation), then the handler
will be apparent to the call to ERROR, but will no longer be a valid target
(its extent was exited by the RETURN in the UNWIND-PROTECT body).
The extent of an object with dynamic extent is the extent of the form
which created it. Code which is executed "within" that form is within
the extent of the object(s). This applies to all dynamic objects, such
as special variable bindings, not just exits. Actually, I think the intent
of the implementation note on p.142 is fairly clear and supports this
interpretation. The supposedly ambiguous use of "frame" should be read
as something like "form which establishes a dynamic extent". It might be
clearer if the last sentence were changed to read something like:
"On the second pass the stack is actually unwound. Each form which establishes
a dynamic extent is undone in reverse order of creation until the matching
CATCH is reached. The meaning of undoing a form depends on the type of form.
For UNWIND-PROTECT, it means executing the cleanup forms. For CATCH it means
removing the CATCH tag. For dynamic bindings it means undoing the binding,
restoring the previous saved value. {This is not an exhaustive listing of the
possibilities.}"
∂04-Apr-89 1301 CL-Cleanup-mailer Issue: PRINT-CIRCLE-SHARED
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 4 Apr 89 12:32:56 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 571250; Tue 4-Apr-89 15:32:49 EDT
Date: Tue, 4 Apr 89 15:32 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: PRINT-CIRCLE-SHARED
To: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <890404153225.9.KMP@BOBOLINK.SCRC.Symbolics.COM>
This was deferred from Tuesday to Thursday but then didn't come up
for discussion.
Since some people (myself included, I think) consider this almost
a clarification, my feeling is that it could still come up at the
next meeting.
∂04-Apr-89 1304 CL-Cleanup-mailer Issue: REAL-NUMBER-TYPE
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 4 Apr 89 12:39:35 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 571267; Tue 4-Apr-89 15:39:27 EDT
Date: Tue, 4 Apr 89 15:38 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: REAL-NUMBER-TYPE
To: CL-Cleanup@SAIL.Stanford.EDU
cc: Cassels@STONY-BROOK.SCRC.Symbolics.COM
Message-ID: <890404153856.3.KMP@BOBOLINK.SCRC.Symbolics.COM>
My notes say...
Barmar moved we accept ``both proposals'' (since one was obviously trying
to include the other, but the wording didn't really make that clear).
The motion to approve both passed 12-3.
∂04-Apr-89 1309 CL-Cleanup-mailer Issue: REQUIRE-PATHNAME-DEFAULTS
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 4 Apr 89 12:41:57 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 571274; Tue 4-Apr-89 15:41:50 EDT
Date: Tue, 4 Apr 89 15:41 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: REQUIRE-PATHNAME-DEFAULTS
To: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <890404154124.5.KMP@BOBOLINK.SCRC.Symbolics.COM>
My notes say...
A motion to reconsider this issue was made.
The motion to reconsider passed 5-4.
A motion was made to deprecate rather than to remove.
Pitman proposed an amendment to make these macros instead of functions,
thinking that REQUIRE and PROVIDE were part of the magic functions we
were trying to eliminate. He tried to withdraw the motion to amend
when someone observed that they are not supposed to be specially treated
but others still wanted them to be macros for some reason. Anyway, the
amendment failed on a vote of 4-11.
The original motion to deprecate instead of remove was voted on.
The first count was 7-7, but someone asked for a recount.
The next count was 7-8, but someone was late raising his hand and didn't
think his vote had counted right.
The next vote was 8-7. At this point, Pitman requested a roll call vote
so there would be no dispute later.
The results were:
IBM No
DEC Yes
RWK(!) Yes
TI No
IIM Yes
Univ of Utah No
Apple Yes
Franz Yes
Think Yes
Encore Yes
Honeywell No
Johnson Controls No
MCC No
Xerox No
Lucid Yes
SMBX No
The motion failed 8-8, so the result voted on at the previous meeting stands.
∂04-Apr-89 1309 CL-Cleanup-mailer Issue: UNDEFINED-VARIABLES-AND-FUNCTIONS
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 4 Apr 89 12:48:24 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 571297; Tue 4-Apr-89 15:48:21 EDT
Date: Tue, 4 Apr 89 15:47 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: UNDEFINED-VARIABLES-AND-FUNCTIONS
To: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <890404154756.1.KMP@BOBOLINK.SCRC.Symbolics.COM>
Deferred until next meeting.
There was some ``off-line'' discussion of slot-unbound with no real resolution.
That part of the issue promises to be a controversial one.
Moon seems to think that one idea that had some support is to say that the
system-defined method "should signal an error", depending on the safety level
of the original call to SLOT-VALUE, so the generic function is only called if
the SLOT-VALUE is safe or user-defined methods might be applicable. I haven't
had time to decide whether I understand this enough to either agree or disagree.
∂04-Apr-89 1309 CL-Cleanup-mailer Issue: TYPE-OF-UNDERCONSTRAINED
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 4 Apr 89 12:47:07 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 571292; Tue 4-Apr-89 15:46:55 EDT
Date: Tue, 4 Apr 89 15:46 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: TYPE-OF-UNDERCONSTRAINED
To: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <890404154630.0.KMP@BOBOLINK.SCRC.Symbolics.COM>
Some people had some concerns about a previous version of this that passed.
We wanted to reconsider this, but didn't have the right hardcopy.
No action was taken. This will probably come up next meeting.
∂04-Apr-89 1324 CL-Cleanup-mailer issue DYNAMIC-EXTENT-FUNCTION, version 1
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 4 Apr 89 13:24:20 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 571355; Tue 4-Apr-89 16:23:51 EDT
Date: Tue, 4 Apr 89 16:23 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: issue DYNAMIC-EXTENT-FUNCTION, version 1
To: Sandra J Loosemore <sandra%defun@cs.utah.edu>
cc: cl-cleanup@sail.stanford.edu
In-Reply-To: <8904041727.AA19101@defun.utah.edu>
Message-ID: <19890404202338.6.MOON@EUPHRATES.SCRC.Symbolics.COM>
Comments on current practice:
This is very different from Symbolics Genera current practice, which
I would describe as follows:
First, if a function A has a DYNAMIC-EXTENT declaration for one of its
parameters F, and a caller of A passes a function B as the argument
corresponding to the parameter F, then B is used in a "downward" way.
Calling a function directly or via FUNCALL or APPLY is a "downward" use
too. If every use of a function is "downward", then the compiler
implements the function with dynamic extent (provided the function is
not globally named, but is only locally named or not named at all, i.e.
defined with FLET, LABELS, or LAMBDA). We currently use a different
name for the declaration, instead of DYNAMIC-EXTENT, but that is
unimportant.
Does the compiler committee's model of compilation permit compilation of
one function to be affected by declarations in the current definition of
another function that it calls? I hope so.
Second, if a function has a SYS:DOWNWARD-FUNCTION declaration in front of
its body, then the function is implemented with dynamic extent regardless
of whether the compiler thinks all uses are "downward". This feature is
used less often than the first feature, but is still used pretty often.
An example would be
(funcall (computation-that-returns-a-function)
(function (lambda (...)
(declare (sys:downward-function))
...))
...other args...)
Here the function being called is not known at compile time, so there
is no place from which to obtain a DYNAMIC-EXTENT declaration. In
your proposal, the declaration cannot be made unless the function is
given a name, so this example would have to be rewritten as:
(flet ((dummy-name (...)
...))
(declare (dynamic-extent-function dummy-name))
(funcall (computation-that-returns-a-function)
(function dummy-name)
...other args...))
Third, there is a variation of the first feature by which a function can
declare that all of its arguments are used "downward"; this is
especially useful for declaring arguments that are elements of a list
that is the value of an &rest parameter, since there is no parameter
name corresponding to those arguments. We do this by using * instead of
a parameter name, but I don't see any way to map that into the
DYNAMIC-EXTENT declaration. However, if we were willing to say that the
&rest list also had to have dynamic extent in this case, then a
DYNAMIC-EXTENT declaration of the &rest parameter would imply downward
use of the functions, since otherwise they would not be OIPs (in the
language of the amended DYNAMIC-EXTENT proposal that we just passed).
So I don't think we need this third feature.
The fact that your proposal is different from Symbolics Genera current
practice doesn't mean the proposal is wrong, after all it is also very
different from the current practices of the two implementations listed
in the proposal. But we should think hard about dynamic extent for
anonymous lambdas, which can be quite important in practice.
On a sillier note, should we minimize proliferation of names by
replacing
(declare (dynamic-extent-function name))
with
(declare (dynamic-extent #'name)) ?
This is a serious proposal, although I suspect that some people
will think it is a stupid idea.
∂04-Apr-89 1531 CL-Cleanup-mailer Issue: COPY-SYMBOL-PRINT-NAME (not COPY-SYMBOL-COPY-PRINT-NAME)
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 4 Apr 89 15:31:00 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 571454; Tue 4-Apr-89 18:30:52 EDT
Date: Tue, 4 Apr 89 18:30 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: COPY-SYMBOL-PRINT-NAME (not COPY-SYMBOL-COPY-PRINT-NAME)
To: CL-Cleanup@SAIL.Stanford.EDU
Supersedes: <890404113419.4.KMP@BOBOLINK.SCRC.Symbolics.COM>
Message-ID: <890404183026.9.KMP@BOBOLINK.SCRC.Symbolics.COM>
Date: Tue, 4 Apr 89 11:34 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: COPY-SYMBOL-COPY-PRINT-NAME
To: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <890404113419.4.KMP@BOBOLINK.SCRC.Symbolics.COM>
My notes say this passed unanimously.
The issue name was COPY-SYMBOL-PRINT-NAME, of course.
Sorry for the typo. Hope this didn't confuse anyone.
∂04-Apr-89 2058 CL-Cleanup-mailer issue DYNAMIC-EXTENT-FUNCTION, version 1
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 4 Apr 89 20:58:35 PDT
Received: from bhopal ([192.9.200.13]) by heavens-gate.lucid.com id AA17233g; Tue, 4 Apr 89 20:52:50 PDT
Received: by bhopal id AA11925g; Tue, 4 Apr 89 20:59:22 PDT
Date: Tue, 4 Apr 89 20:59:22 PDT
From: Jon L White <jonl@lucid.com>
Message-Id: <8904050359.AA11925@bhopal>
To: sandra%defun@cs.utah.edu
Cc: cl-cleanup@sail.stanford.edu
In-Reply-To: Sandra J Loosemore's message of Tue, 4 Apr 89 11:27:21 MDT <8904041727.AA19101@defun.utah.edu>
Subject: issue DYNAMIC-EXTENT-FUNCTION, version 1
re: Introduce a new declaration called DYNAMIC-EXTENT-FUNCTION. This is
identical to the DYNAMIC-EXTENT declaration, except that the
arguments name functions instead of variables.
This is not sufficiently clear for a "specification". I think you should
at least talk about how the DYNAMIC-EXTENT-FUNCTION declaration only applies
to lexical functions defined via FLET and LABELS, and is not to be used in
a proclamation.
Additionally, you will have to say, for a form like:
(locally (declare (dynamic-extent-function f g))
(labels ((f (x) ...)
(g (y) ...)
(h (z) ...))
(declare <more-declarations>)
...))
whether or not the declaration in the LOCALLY is to apply to the two
functions, or whether it has to be supplied in the place indicated by
<more-declarations> [my first inclination is that it doesn't apply,
since similar program structure for type declarations wouldn't apply.]
Similarly, you will have to say whether or not there is such a thing
as a "free" dynamic-extent-function declaration. E.g., what does
the following mean:
(flet ((f (x) ...))
(funcall f gobbledygook)
(locally (declare (dynamic-extent-function f))
(cogitate #'f))
t)
Here, my inclination is that unless the dynamic-extent-function declaration
is applied to the name binding, it is useless to the compiler. It's a bit
like allowing the compiler to represent FLOATs in specialized storage,
providing it knows that during the entire lifetime of the variable --
including the binding time -- the value will only be FLOAT [hence, it can,
e.g., use the flonum pdl instead of "boxing up" the value in the heap]
Finally, you have to say how you handle a case like:
(mapcar (the dynamic-extent-function #'(lambda (x) <capture-stuff>))
...)
and if so, how to specify the particular dynamic scope of interest.
Or, maybe you don't want to handle "anonymous" lexical functions. [By
the bye, I realize that 'dynamic-extent-function' isn't a type -- I
only wanted to illustrate the problem for "anonymous" functions.]
If the places where the two declarations DYNAMIC-EXTENT-FUNCTION and
DYNAMIC-EXTENT can be legitimately used don't overlap, then I don't
see anything wrong with using the same name. E.g.,
(let ((x (make-list n :initial-element 0)))
(declare (dynamic-extent x))
(labels ((f (y z) ...))
(declare (dynamic-extent f))
. . . ))
should be unambiguous.
-- JonL --
P.S. The fact that I'm replying to a msg sent today doesn't mean that
I'm not still 4 weeks behind (in general) in mail reading.
∂05-Apr-89 0710 CL-Cleanup-mailer Re: issue DYNAMIC-EXTENT-FUNCTION, version 1
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 5 Apr 89 07:10:33 PDT
Received: from defun.utah.edu by cs.utah.edu (5.61/utah-2.1-cs)
id AA14298; Wed, 5 Apr 89 08:10:27 -0600
Received: by defun.utah.edu (5.61/utah-2.0-leaf)
id AA19876; Wed, 5 Apr 89 08:10:22 -0600
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8904051410.AA19876@defun.utah.edu>
Date: Wed, 5 Apr 89 08:10:21 MDT
Subject: Re: issue DYNAMIC-EXTENT-FUNCTION, version 1
To: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Cc: Sandra J Loosemore <sandra%defun@cs.utah.edu>,
cl-cleanup@sail.stanford.edu
In-Reply-To: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>, Tue, 4 Apr 89 16:23 EDT
> Date: Tue, 4 Apr 89 16:23 EDT
> From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
>
> Does the compiler committee's model of compilation permit compilation of
> one function to be affected by declarations in the current definition of
> another function that it calls? I hope so.
Issue COMPILE-ENVIRONMENT-CONSISTENCY talks about situations in which
the compiler is allowed to assume that functions defined in the
compiletime environment retain the same definitions at runtime. I
don't see anything wrong with applying this technique in those
situations.
> Second, if a function has a SYS:DOWNWARD-FUNCTION declaration in front of
> its body, then the function is implemented with dynamic extent regardless
> of whether the compiler thinks all uses are "downward". This feature is
> used less often than the first feature, but is still used pretty often.
I vaguely remembered seeing this in some ancient Symbolics
documentation. It seems a little strange to me to have a declaration
that is only valid in one particular place, but this would indeed take
care of the problem with anonymous lambdas.
> On a sillier note, should we minimize proliferation of names by
> replacing
>
> (declare (dynamic-extent-function name))
>
> with
>
> (declare (dynamic-extent #'name)) ?
I wouldn't have any strong objection to doing this, but maybe I'm
being silly too. :-)
-Sandra
-------
∂05-Apr-89 0721 CL-Cleanup-mailer Re: issue DYNAMIC-EXTENT-FUNCTION, version 1
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 5 Apr 89 07:21:47 PDT
Received: from defun.utah.edu by cs.utah.edu (5.61/utah-2.1-cs)
id AA14975; Wed, 5 Apr 89 08:21:43 -0600
Received: by defun.utah.edu (5.61/utah-2.0-leaf)
id AA19890; Wed, 5 Apr 89 08:21:40 -0600
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8904051421.AA19890@defun.utah.edu>
Date: Wed, 5 Apr 89 08:21:39 MDT
Subject: Re: issue DYNAMIC-EXTENT-FUNCTION, version 1
To: Jon L White <jonl@lucid.com>
Cc: sandra%defun@cs.utah.edu, cl-cleanup@sail.stanford.edu
In-Reply-To: Jon L White <jonl@lucid.com>, Tue, 4 Apr 89 20:59:22 PDT
I don't want to downplay your concerns, but it ought to be pointed out
that all of the problems you mention also apply to the DYNAMIC-EXTENT
declaration proposal that we have already accepted. (The only
difference between the two is that DYNAMIC-EXTENT declarations apply
to variable bindings and DYNAMIC-EXTENT-FUNCTION declarations apply to
function bindings.) Maybe I'm extrapolating beyond what was actually
stated in issue DECLARATION-SCOPE, but there's no confusion in my mind
about the scope of these two particular declarations, or what it means
for them to appear "free".
-Sandra
-------
∂05-Apr-89 0805 CL-Cleanup-mailer Re: Issue: LISP-SYMBOL-REDEFINITION
Received: from multimax.encore.com by SAIL.Stanford.EDU with TCP; 5 Apr 89 08:05:21 PDT
Received: from mist.encore.COM by multimax.encore.com with SMTP (5.61/25-eef)
id AA05665; Wed, 5 Apr 89 11:05:04 -0400
Received: from localhost by mist. (4.0/SMI-4.0)
id AA04672; Wed, 5 Apr 89 11:06:53 EDT
Message-Id: <8904051506.AA04672@mist.>
To: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Cc: "sandra%defun@SAIL.Stanford.EDU"@multimax.encore.com,
CL-Cleanup@SAIL.Stanford.EDU
Subject: Re: Issue: LISP-SYMBOL-REDEFINITION
In-Reply-To: Your message of Tue, 04 Apr 89 14:58:00 -0400.
Date: Wed, 05 Apr 89 11:06:51 EDT
From: Dan L. Pierson <pierson@mist.encore.com>
Ultimately, I have written in my notes that we voted on
``proposal replaced by RPG, item 8 struck, w/ Sandra's prohibition
to trace local functions''
and that it passed 14-3.
My note agree with this interpretation.
∂05-Apr-89 0848 CL-Cleanup-mailer issue DYNAMIC-EXTENT-FUNCTION, version 1
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 5 Apr 89 08:47:55 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 571732; Wed 5-Apr-89 11:47:23 EDT
Date: Wed, 5 Apr 89 11:47 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: issue DYNAMIC-EXTENT-FUNCTION, version 1
To: Jon L White <jonl@lucid.com>
cc: sandra%defun@cs.utah.edu, cl-cleanup@sail.stanford.edu
In-Reply-To: <8904050359.AA11925@bhopal>
Message-ID: <19890405154713.0.MOON@EUPHRATES.SCRC.Symbolics.COM>
It's my belief that a close reading of the GLS and KMP amendment to
DYNAMIC-EXTENT (which was passed out at the meeting last week and
was unanimously adopted by X3J13 provides an unambiguous answer to
each of your concerns.
∂05-Apr-89 1159 CL-Cleanup-mailer Issue: DYNAMIC-EXTENT (Version 4)
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 5 Apr 89 11:59:13 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 571894; Wed 5-Apr-89 14:59:05 EDT
Date: Wed, 5 Apr 89 14:58 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: DYNAMIC-EXTENT (Version 4)
To: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <890405145837.2.KMP@BOBOLINK.SCRC.Symbolics.COM>
This was approved but it was so piecemeal it was hard to read so I produced
a new copy for reference.
I made the changes per our meeting and also changed some usages of
"proper part" in the examples to refer to OIP's instead. I trimmed
from the Discussion and Additional Discussion those things which seemed
no longer relevant.
I hope this fairly represents the current state of what was approved.
-----
Forum: Cleanup
Issue: DYNAMIC-EXTENT
References: Scope and Extent
Category: ADDITION
Edit history: 27-Jun-88, Version 1 by Pitman (as issue STACK-LET)
15-Nov-88, Version 2 by Pitman (issue renamed, major revision)
11-Jan-89, Version 3 by Masinter (Moon's proposal)
05-Apr-89, Version 4 by Pitman and Steele (changes per X3J13)
Related-Issues: REST-ARGUMENT-EXTENT, WITH-DYNAMIC-EXTENT
Status: Accepted DYNAMIC-EXTENT:X3J13-MAR-89, 30-Mar-89 on a 17-0 vote.
Problem Description:
Sometimes a programmer knows that a particular data structure
will have only dynamic extent. In some implementations, it is
possible to allocate such structures in a way that will make them
easier to reclaim than by general purpose garbage collection
(eg, on the stack or in some temporary area). Currently, however,
there is no way to request the use of such an allocation mechanism.
Proposal (DYNAMIC-EXTENT:NEW-DECLARATION):
Introduce a new declaration called DYNAMIC-EXTENT. The arguments to
this declaration are names of variables.
It is permissible for an implementation to simply ignore this declaration.
In implementations which do not ignore it, the compiler (or interpreter)
is free to make whatever optimizations are appropriate given this
information; the most common optimization is to stack-allocate the
initial value of the object. What data types (if any) can have dynamic
extent will can vary from implementation to implementation.
Definition: Object <x> is an ``otherwise inaccessible part'' (OIP)
of <y> iff making <y> inaccessible would make <x> inaccessible.
(Note that every object is an OIP of itself.)
Suppose that construct <c> contains a DYNAMIC-EXTENT declaration for
variable <v> (which need not be bound by <c>). Consider the values
<w1>, ..., <wN> taken on by <v> during the course of some execution of
<c>. The declaration asserts that if object <x> is an OIP of <wI>
when <wI> ever becomes the value of <v>, then just after execution of
<c> terminates <x> will be either inaccessible or still an OIP of <v>.
If the assertion is ever violated, the conseqeuences are undefined.
Examples:
Since stack allocation of the initial value entails knowing at the
object's creation time that the object can be stack-allocated, it is
not generally useful to declare DYNAMIC-EXTENT for variables for
which have no lexically apparent initial value. For example,
(DEFUN F ()
(LET ((X (LIST 1 2 3)))
(DECLARE (DYNAMIC-EXTENT X))
...))
would permit those compilers which wish to do so to stack-allocate the
list in X. However,
(DEFUN G (X) (DECLARE (DYNAMIC-EXTENT X)) ...)
(DEFUN F () (G (LIST 1 2 3)))
could not typically permit a similar optimization in G because it would
be a modularity violation for the compiler to assume facts about G from
within F. Only an implementation which was willing to be responsible for
recompiling F if G's definition changed incompatibly could stack-allocate
the list argument to G in F.
Other interesting cases are:
(PROCLAIM '(INLINE G))
(DEFUN G (X) (DECLARE (DYNAMIC-EXTENT X)) ...)
(DEFUN F () (G (LIST 1 2 3)))
and (DEFUN F ()
(FLET ((G (X) (DECLARE (DYNAMIC-EXTENT X)) ...))
(G (LIST 1 2 3))))
where some compilers might realize the optimization was possible and others
might not.
An interesting variant of this is the so-called `stack allocated rest list'
which can be achieved (in implementations supporting the optimization) by:
(DEFUN F (&REST X)
(DECLARE (DYNAMIC-EXTENT X))
...)
Note here that although the initial value of X is not explicit, the F
function is responsible for assembling the list X from the passed arguments,
so the F function can be optimized by the compiler to construct a
stack-allocated list instead of a heap-allocated list in implementations
which support such.
In
(LET ((X (LIST 'A1 'B1 'C1))
(Y (CONS 'A2 (CONS 'B2 (CONS 'C2 NIL)))))
(DECLARE (DYNAMIC-EXTENT X Y))
...)
The OIP's of X are three conses, and the OIP's of Y are three other
conses. None of the symbols A1, B1, C1, A2, B2, C2, or NIL is an
OIP of X or Y. However, if a freshly allocated uninterned symbol had
been used, it would have been an OIP.
- - - - - - - -
(DOTIMES (I N)
(DECLARE (DYNAMIC-EXTENT I))
This is particularly instructive. Since I is an integer by the
definition of DOTIMES, but EQ and EQL are not necessarily equivalent for
integers, what are the OIP's of I, which this declaration
requires the body of the DOTIMES not to "save"? If the value of I is 3,
and the body does (SETQ FOO 3), is that an error? The answer is no, but
the interesting thing is that it depends on the implementation-dependent
behavior of EQ on numbers. In an implementation where EQ and EQL are
equivalent for 3, then 3 is not an OIP because (EQ I (+ 2 1)) is true,
and therefore there is another way to access the object besides
going through I. On the other hand, in an implementation where EQ and
EQL are not equivalent for 3, then the particular 3 that is the value of
I is an OIP, but any other 3 is not. Thus (SETQ FOO 3) is valid
but (SETQ FOO I) is erroneous. Since (SETQ FOO I) is erroneous in some
implementations, it is erroneous in all portable programs, but some other
implementations may not be able to detect the error.
- - - - - - - -
(LET ((X (LIST 1 2 3)))
(DECLARE (DYNAMIC-EXTENT X))
(PRINT X)
NIL)
PRINT does not "save" any part of its input.
This prints (1 2 3)
- - - - - - - -
(DO ((L (LIST-ALL-PACKAGES) (CDR L)))
((NULL L))
(DECLARE (DYNAMIC-EXTENT L))
(PRINT (CAR L)))
prints all packages; none of the newly-allocated list structures are saved.
- - - - - - - -
(DEFUN ADD (&REST X) (DECLARE (DYNAMIC-EXTENT X)) (APPLY #'+ X))
(ADD 1 2 3) => 6
I.e., useful way to declare that &REST lists have dynamic extent
- - - - - - - -
(DEFUN ZAP (X Y Z)
(DO ((L (LIST X Y Z) (CDR L)))
((NULL L))
(DECLARE (DYNAMIC-EXTENT L))
(PRIN1 (CAR L))))
(ZAP 1 2 3)
prints 123
- - - - - - - -
(DEFUN ZAP (N M)
;; Computes (RANDOM (+ M 1)) at relative speed of roughly O(N).
;; It may be slow, but with a good compiler at least it
;; doesn't waste much heap storage. :-)
(LET ((A (MAKE-ARRAY N)))
(DECLARE (DYNAMIC-EXTENT A))
(DOTIMES (I N)
(DECLARE (DYNAMIC-EXTENT I))
(SETF (AREF A I) (RANDOM (+ I 1))))
(AREF A M)))
(< (ZAP 5 3) 3) => T
- - - - - - - -
The following are in error, since the value of X is used outside of its
extent:
(LENGTH (LIST (LET ((X (LIST 1 2 3))) (DECLARE (DYNAMIC-EXTENT X)) X)))
(PROGN (LET ((X (LIST 1 2 3))) (DECLARE (DYNAMIC-EXTENT X)) X)
NIL)
- - - - - - - -
Rationale:
This permits a programmer to offer advice to an implementation about
what may be stack-allocated for efficiency.
It may be difficult or impossible for a compiler to infer this
same information statically.
Since a number of implementations offer this capability and there
is demand from users for access to the capability, this ``codifies
existing practice.''
Because this approach is purely lexical, it does not interact badly with
other programs in the way that the macro WITH-DYNAMIC-EXTENT (see issue
by same name) would.
Current Practice:
Symbolics Genera and Symbolics Cloe offer stack allocation, though not
in this strategy.
[KMP thinks that] Lucid supports the proposal.
Cost to Implementors:
No cost is forced since implementations are permitted to simply
ignore the DYNAMIC-EXTENT declaration.
Cost to Users:
None. This change is upward compatible.
There may be some hidden costs to debugging using this declaration (or any
feature which permits the user to access dynamic extent objects without
the compiler proving that they are appropriate). If the user misdeclares
something and returns a pointer into the stack (or stores it in the heap),
an undefined situation may result and the integrity of the Lisp storage
mechanism may be compromised. Debugging these situations may be tricky,
but users who have asked for this feature have indicated a willingness
to deal with such costs. Nevertheless, the perils should be clearly
documented and casual users should not be encouraged to use this
declaration.
Cost of Non-Adoption:
Some portable code would be forced to run more slowly (due to
GC overhead), or to use non-portable language features.
Benefits:
The cost of non-adoption is avoided.
Aesthetics:
This declaration allows a fairly low level optimization to work
by asking the user to provide only very high level information.
The alternatives (sharpsign conditionals, some of which may
lead to more bit-picky abstractions) are far less aesthetic.
Discussion:
A previous version of this proposal suggested primitives STACK-LET
and STACK-LET*. Consensus was that the more general declaration facility
would be more popular.
Moon came up with a description of something called a "proper part" which
Steele formalized into the idea of an "otherwise inaccessible part". The
two are essentially interchangeable, but Steele's description was more
rigorous.
KMP: ... it still raises the question of whether we should define
per-function for every CL function whether any of the arguments is
permitted to be "saved" so that CL programs don't get any funny
surprises. If we don't, it ends up being implementor's discretion how
to resolve cases ... and everyone might not agree that all cases are
... obvious ...
JonL: PDP10 MacLisp had a similar problem w.r.t pdlnums. That is why
"identity" functions were so troublsome for it -- in order to
return a guaranteed safe value, it typically had to copy it's
pdlnum argument, thereby making some cases of "fast arithmetic"
code much worse than interpreted code! [Remember PRINT in MacLisp?
it returns T rather than it's argument for just this reason.]
It is necessary for an optimizing compiler to know something about
what happens to the data it passes along to "system" functions; for
example, it could assume that GET doesn't clobber the list given
to it, nor does it retain pointers to any part of it [what was the
terminology in the revised proposal? "saved"? and "proper part"?]
The issue LISP-SYMBOL-REDEFINITION might help here, in that an
implementation's compilers could depend upon it's own internal
database. But it wouldn't hurt at all to have some of these
requirements "up front" in the standard.
It was generally agreed that we would also like to consider a proposal
on dynamic extent functions at the next meeting. (Sandra said she would
prepare one, and has already done so. See issue DYNAMIC-EXTENT-FUNCTION.)
∂05-Apr-89 1206 CL-Cleanup-mailer Issue: DYNAMIC-EXTENT (Version 4)
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 5 Apr 89 12:06:04 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 571908; Wed 5-Apr-89 15:06:07 EDT
Date: Wed, 5 Apr 89 15:05 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: DYNAMIC-EXTENT (Version 4)
To: CL-Cleanup@SAIL.Stanford.EDU
In-Reply-To: <890405145837.2.KMP@BOBOLINK.SCRC.Symbolics.COM>
Message-ID: <890405150540.4.KMP@BOBOLINK.SCRC.Symbolics.COM>
Sigh. As you can probably tell, I meant to change the name of the
proposal from NEW-DECLARATION to X3J13-MAR-89 like Masinter's been
doing and I only did it half-way. There's only one proposal so
please don't be confused. Anyway, the text is right so I'm gonna
leave it...
∂05-Apr-89 1731 CL-Cleanup-mailer issue DYNAMIC-EXTENT-FUNCTION, version 1
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 5 Apr 89 17:31:35 PDT
Received: from bhopal ([192.9.200.13]) by heavens-gate.lucid.com id AA00786g; Wed, 5 Apr 89 17:25:35 PDT
Received: by bhopal id AA04722g; Wed, 5 Apr 89 17:32:08 PDT
Date: Wed, 5 Apr 89 17:32:08 PDT
From: Jon L White <jonl@lucid.com>
Message-Id: <8904060032.AA04722@bhopal>
To: Moon@STONY-BROOK.SCRC.Symbolics.COM
Cc: sandra%defun@cs.utah.edu, cl-cleanup@sail.stanford.edu
In-Reply-To: David A. Moon's message of Wed, 5 Apr 89 11:47 EDT <19890405154713.0.MOON@EUPHRATES.SCRC.Symbolics.COM>
Subject: issue DYNAMIC-EXTENT-FUNCTION, version 1
re: It's my belief that a close reading of the GLS and KMP amendment to
DYNAMIC-EXTENT (which was passed out at the meeting last week and
was unanimously adopted by X3J13 provides an unambiguous answer to
each of your concerns.
Well, the difficulty centers on how one interprets the word "identical"
in Sandra's proposal. I would invite you to make your interpretation,
and put it into unambiguous words, explicitly in this proposal.
By the bye, do you agree that a single declaration name -- DYNAMIC-EXTENT
-- is satisfactory for both contexts? A reasonable alternative might
simply be to amend the previously passed proposal to include the function
context.
-- JonL --
∂05-Apr-89 2203 CL-Cleanup-mailer issue DYNAMIC-EXTENT-FUNCTION, version 1
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 5 Apr 89 22:03:16 PDT
Received: from bhopal ([192.9.200.13]) by heavens-gate.lucid.com id AA00980g; Wed, 5 Apr 89 21:57:29 PDT
Received: by bhopal id AA05644g; Wed, 5 Apr 89 22:03:57 PDT
Date: Wed, 5 Apr 89 22:03:57 PDT
From: Jon L White <jonl@lucid.com>
Message-Id: <8904060503.AA05644@bhopal>
To: sandra%defun@cs.utah.edu
Cc: cl-cleanup@sail.stanford.edu
In-Reply-To: Sandra J Loosemore's message of Wed, 5 Apr 89 08:21:39 MDT <8904051421.AA19890@defun.utah.edu>
Subject: issue DYNAMIC-EXTENT-FUNCTION, version 1
re: . . .all of the problems you mention also apply to the DYNAMIC-EXTENT
declaration proposal that we have already accepted. (The only
difference between the two is that DYNAMIC-EXTENT declarations apply
to variable bindings and DYNAMIC-EXTENT-FUNCTION declarations apply to
function bindings.)
This can't be true -- for example, there is no such thing as
"anonymous variables" in the way that lambda-forms are anonymous
functions. And as Moon's recounting of the current Symbolics model
shows, downward lambdas can be very important.
However, I was mostly concerned about the possibility that two
readers might interpret your wording "identical" in somwhat
non-identical ways.
-- JonL --
∂06-Apr-89 1115 CL-Cleanup-mailer Condensed summary of CL Cleanup meeting results
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 6 Apr 89 11:15:35 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 572595; Thu 6-Apr-89 14:15:30 EDT
Date: Thu, 6 Apr 89 14:14 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Condensed summary of CL Cleanup meeting results
To: CL-Cleanup@SAIL.Stanford.EDU
cc: chapman%aitg.dec@decwrl.dec.com
Message-ID: <890406141456.6.KMP@BOBOLINK.SCRC.Symbolics.COM>
Kathy Chapman asked for the information that was in my last burst of
messages in some sort of `summary' form. I had chosen to send out
individual messages because I assumed most people like myself who were
doing per-topic filing would find that simpler. But for those who are
just auditing this stuff and deleting it, here's my summary.
Just a reminder though -- these are just my notes and do not necessarily
represent the official story if it turns out there are discrepancies.
-----
ADJUST-ARRAY-NOT-ADJUSTABLE - Deferred
BREAK-ON-WARNINGS-OBSOLETE - Passed
CLOS-CONDITIONS - Passed
CLOS-MACRO-COMPILATION - Tabled
CLOSED-STREAM-OPERATIONS -
Motion to replace v7 with v5 passed unamended
COERCE-INCOMPLETE - Withdrawn
COMMON-TYPE - Passed
COMPLEX-RATIONAL-RESULT - Passed
CONDITION-RESTARTS - Deferred
COPY-SYMBOL-COPY-PLIST - Passed
COPY-SYMBOL-COPY-PRINT-NAME - Passed
DECLARE-FUNCTION-AMBIGUITY -
An incredibly weird vote on the question ``How many favor saying it passed
at the last meeting?'' passed N-0-M.
DEFINE-OPTIMIZER - Failed
There is new information which leads me to believe this might come up
again at the next meeting.
DEFMACRO-LAMBDA-LIST -
There were hardcopy amendments distributed.
My notes say that we approved amendments A & B (``permit all four'')
and we added an amendment that said that &ENVIRONMENT would not be
duplicated in a DEFMACRO lambda-list.
The amended proposal was passed N-0-1.
DESCRIBE-UNDERSPECIFIED -
An amendment was made (I think by Barrett) to make DESCRIBE deal with
its second argument in the same way as PRINT does (that is, permitting
arguments of NIL and T).
The amended proposal passed 15-0.
DESTRUCTURING-BIND
Discussion on this was broken over two days with quite a number of
possible amendments discussed. Pitman came up with a written set of
amendments for Thursday which were discarded because Moon submitted a
revised proposal (consistent with those amendments, and adding at least
one other feature not covered in those separate amendments) on Thursday.
The revised proposal was v3, already mailed.
Moon's revised proposal was voted on, and passed 15-1.
DYNAMIC-EXTENT -
Steele and Pitman drafted a revised proposal over lunch Thursday
which passed 17-0.
EQUALP-GENERIC - Withdrawn
ERROR-CHECKING-IN-NUMBERS-CHAPTER - Deferred
ERROR-NOT-HANDLED -
Withdrawn in favor of providing Kathy with editorial advice to
`minimize implicit requirements on debuggers' in the presentation of the
debugger in the standard.
EVAL-WHEN-NON-TOP-LEVEL - Option GENERALIZE-EVAL-NEW-KEYWORDS passed
EXIT-EXTENT -
Moon offered some amendments the effect of which were to allow you to throw again
to the same tag as you were already throwing to; specifically:
In the first paragraph of the MINIMAL proposal, delete "or is itself the
target exit" and change "events (c) and (d) at" to "event (c) occurs at".
After the first paragraph add a new paragraph "The event (d) occurs at the
end of the transfer of control."
The proposal was amended, and the amended option MINIMAL passed 11-5.
FUNCTION-COERCE-TIME -
Withdrawn; editors were instructed to be explicitly vague 16-1.
FUNCTION-NAME -
The net effect is that option LARGE passed with amendments to strike 7,8,9.
GENSYM-NAME-STICKINESS - Passed
HASH-TABLE-ACCESS -
Passed 17-0 with hand-written amendments by Pitman (and agreement that the
`obvious' write-o's would be corrected).
HASH-TABLE-SIZE - Deferred
IN-PACKAGE-FUNCTIONALITY -
The net effect is that NEW-MACRO passed with the name of SELECT-PACKAGE
changed to IN-PACKAGE.
IN-SYNTAX -
Version 2, which makes LOAD and *COMPILE-FILE* bind *READTABLE* (and
which does -not- introduce the IN-SYNTAX macro mentioned in version 1)
passed 12-0-3. This version was distributed by KMP in handwritten form.
LISP-PACKAGE-NAME -
The net effect is that this passed with amendment to rename package USER to
COMMON-LISP-USER with nickname CL-USER.
LISP-SYMBOL-REDEFINITION -
GZ wanted an amendment to strike item 8 from this list.
Sandra had some concern about the penultimate paragraph where she wanted a
prohibition on the ability to trace local functions (in implementations that
permit that). Moon thinks the proposal was amended to explicitly allow
tracing of such local function bindings.
We went round in circles about item 8. A straw poll to send this back for
more work failed 6-10, so we kept on.
A motion was made to terminate discussion. This passed by 2/3 vote.
Moon's notes say item 8 may need further refinement, as for instance by GLS's
amendment. The goal is to separate properties into the ones the user can
bash and the ones the user cannot bash.
Ultimately, I have written in my notes that we voted on
``proposal replaced by RPG, item 8 struck, w/ Sandra's prohibition
to trace local functions''
and that it passed 14-3.
Item 8 might be revisited at the next meeting.
LOAD-OBJECTS -
Moon proposed friendly amendment to use the name MAKE-LOAD-FORM-SAVING-SLOTS.
The amended proposal passed 18-0.
LOAD-TRUENAME - Deferred
LOCALLY-TOP-LEVEL - Passed
LOOP-AND-DISCREPANCY - Passed
MACRO-CACHING -
Tabled Tuesday. Not re-raised Thursday.
Might or might not come up at next meeting.
MACRO-ENVIRONMENT-EXTENT - option DYNAMIC passed 15-1.
MAKE-STRING-FILL-POINTER - Withdrawn
PACKAGE-FUNCTION-CONSISTENCY -
This was on the agenda but not discussed.
I expect it will come up at the next meeting.
PATHNAME-CANONICAL-TYPE - Deferred
PATHNAME-COMPONENT-CASE - Deferred
PATHNAME-COMPONENT-VALUE - Deferred
PATHNAME-LOGICAL - Deferred (but not seriously expected to come up again)
PATHNAME-PRINT-READ -
This was deferred from Tuesday to Thursday but then didn't come
around for discussion due to lack of time.
It might come up at the next meeting.
PATHNAME-SUBDIRECTORY-LIST - Deferred
PATHNAME-SYNTAX-ERROR-TIME - Deferred
PATHNAME-WILD - Deferred
PEEK-CHAR-READ-CHAR-ECHO -
Kim Barrett mentioned again that he wants to reopen this, but nothing was done.
PRETTY-PRINT-INTERFACE - Deferred
PRINT-CASE-PRINT-ESCAPE-INTERACTION -
This was deferred from Tuesday to Thursday but then didn't come up
for discussion. Being a clarification, I expect it to come up at the
next meeting.
PRINT-CIRCLE-SHARED -
This was deferred from Tuesday to Thursday but then didn't come up
for discussion. Since some people consider this almost a clarification,
this might come up at the next meeting.
PROCLAIM-LEXICAL - Failed
READ-CASE-SENSITIVITY - Deferred
READ-DELIMITED-LIST-EOF -
This issue was mentioned but was not on my list of possible topics.
No action was taken. It's probably a clarification and I guess it might
still come up later.
REAL-NUMBER-TYPE - Passed (the `union' of the two proposals)
REMF-DESTRUCTION-UNSPECIFIED - Passed
REQUIRE-PATHNAME-DEFAULTS -
Reconsidered but no change made. Previous vote stands.
SETF-MULTIPLE-STORE-VARIABLES -
This was on the agenda but never gotten to.
I think it might come up at the next meeting.
SYMBOL-MACROLET-SEMANTICS - Version 6 passed.
SYNTACTIC-ENVIRONMENT-ACCESS - Deferred
THE-AMBIGUITY -
This didn't come up. Being a clarification, I assume it might come up next meeting.
TIME-ZONE-NON-INTEGER
Moon proposed time zones be multiples of 1/3600 so that they were
even numbers of seconds. (Some people suspected this was a subtle
marketing ploy for Symbolics.) This amendment was accepted 11-0.
Pitman proposed that we limit time zone to the range [-24,24], inclusive.
The inclusive was to allow countries to disagree on which end was open,
since it was agreed that the correct value here is a largely political,
rather than technical issue. The amendment was accepted 8-5.
The full proposal with both amendments passed 18-0.
TYPE-OF-UNDERCONSTRAINED -
Some people had some concerns about a previous version of this that passed.
We wanted to reconsider this, but didn't have the right hardcopy.
No action was taken. This will probably come up next meeting.
UNDEFINED-VARIABLES-AND-FUNCTIONS - Deferred
WITH-COMPILATION-UNIT -
This passed 11-6 with an amendment to say it defers "warnings" rather than "actions"
and with an amendment to say it does not apply to the COMPILE function (only to
COMPILE-FILE).
∂09-Apr-89 0921 CL-Cleanup-mailer Issue COMPLEX-RATIONAL-RESULT, version 2
Received: from Think.COM by SAIL.Stanford.EDU with TCP; 9 Apr 89 09:21:18 PDT
Return-Path: <gls@Think.COM>
Received: from brigit.think.com by Think.COM; Sun, 9 Apr 89 12:20:54 EDT
Received: by brigit.think.com; Sun, 9 Apr 89 01:37:19 EDT
Date: Sun, 9 Apr 89 01:37:19 EDT
From: gls@Think.COM
Message-Id: <8904090537.AA00468@brigit.think.com>
To: cl-cleanup@sail.stanford.edu
Cc: gls@Think.COM
Subject: Issue COMPLEX-RATIONAL-RESULT, version 2
This was a good thing for Moon to bring up, but I think a couple
of desirable details were left uncovered. Here is a new version
to consider in June.
Detail 1 is that a mathematically rational or complex rational
value might result from arguments that are a mixture of rational
and complex rational; or a complex rational value might result
from arguments that are rational only.
Detail 2 is that the version 1 proposal mentions (complex float)
where I believe the more specific (complex single-float) is appropriate.
Detail 3 is that in some cases the option of an ordinary float
result is desirable or required rather than a (complex single-float);
consider the ABS function, for example.
Detail 4 is that if the true mathematical result is not rational
or complex rational, I think we want to specify that the returned
value is single-float or (complex single-float).
----------------------------------------------------------------
Issue: COMPLEX-RATIONAL-RESULT
References: CLtL p.203
Category: CLARIFICATION
Edit history: Version 1, 20-Mar-89, by Moon
Version 2, 08-Apr-89, by Steele
Problem description:
Referring to irrational and transcendental functions, CLtL says:
When the arguments to a function in this section are all rational and
the true mathematical result is also (mathematically) rational, then
unless otherwise noted an implementation is free to return either an
accurate result of type rational or a single-precision floating-point
approximation. If the arguments are all rational but the result cannot
be expressed as a rational number, then a single-precision
floating-point approximation is always returned.
Referring to EXPT, CLtL says:
If the base-number is of type RATIONAL and the power-number is an
INTEGER, the calculation will be exact and the result will be of
type RATIONAL; otherwise a floating-point approximation may result.
What about arguments of type (complex rational)?
Proposal (COMPLEX-RATIONAL-RESULT:EXTEND):
Extend the paragraph quoted above as follows to cover the components
of complex numbers. If the arguments to a function are all of type
(OR RATIONAL (COMPLEX RATIONAL)) and the true mathematical result is
(mathematically) a complex number with rational real and imaginary
parts, then unless otherwise noted an implementation is free to return
either an accurate result of type (OR RATIONAL (COMPLEX RATIONAL)) or
a single-precision floating-point approximation of type SINGLE-FLOAT
(permissible only if the imaginary part of the true mathematical
result is zero) or \cd{(COMPLEX SINGLE-FLOAT). If the arguments are
all of type (OR RATIONAL (COMPLEX RATIONAL)) but the result cannot be
expressed as a rational or complex rational number, then the returned
value will be of type SINGLE-FLOAT (permissible only if the imaginary
part of the true mathematical result is zero) or (COMPLEX SINGLE-FLOAT).
For EXPT of a (COMPLEX RATIONAL) to an integer power, the
calculation must be exact and the result will be of type
(OR RATIONAL (COMPLEX RATIONAL)).
Examples:
(log #c(-16 16) #c(2 2)) => 3 or approximately #c(3.0 0.0)
or approximately 3.0 (unlikely)
(abs #c(3/5 4/5)) => 1 or approximately 1.0
(expt #c(2 2) 3) => #c(-16 16)
(expt #c(2 2) 4) => -64
Rationale:
This seems most consistent with the treatment of real numbers.
Current practice:
Symbolics Genera 7.4 returns a (complex float) for the first example
and returns the specified answers for the second and third examples.
Other implementations were not surveyed.
Cost to Implementors:
Only EXPT would have to change, since the type of the other results
is at the discretion of the implementation.
Cost to Users:
Probably none, but it is hard to predict.
Cost of non-adoption:
Slightly less self-consistent language.
Performance impact:
None of any significance.
Benefits/Esthetics:
More self-consistent language.
Discussion:
None.
∂09-Apr-89 2155 CL-Cleanup-mailer Issue: LISP-SYMBOL-REDEFINITION, v.6
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 9 Apr 89 21:55:03 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 09 APR 89 21:55:03 PDT
Date: 9 Apr 89 21:54 PDT
From: masinter.pa@Xerox.COM
Subject: Issue: LISP-SYMBOL-REDEFINITION, v.6
To: cl-cleanup@SAIL.Stanford.EDU
line-fold: NO
Message-ID: <890409-215503-3430@Xerox>
I've compared my notes against Mary's minutes, and they agree
that we struck 8 and added a phrase "and to trace that binding"
("Sandra's amendment".)
!
Status: Passed, Mar 89 X3J13, as amended
Forum: Cleanup
Issue: LISP-SYMBOL-REDEFINITION
References: Cleanup issue PACKAGE-CLUTTER
CLtL pp 67-69 Defining named functions
Category: CLARIFICATION
Edit history: Masinter, Version 1, 17-Sep-88 from (Kolb, 14-Aug-87)
Masinter, Version 2, 7-Oct-88
Masinter, Version 3, 7-Oct-88, fix typos
van Roggen, Version 4, 13-Oct-88, undefined, not unspecified
Masinter, Version 5, 22-Nov-88, add more cases
Masinter, Version 6, 9-Apr-89, make Mar 89 X3j13 amendments
Problem description:
Is it legal to redefine Common Lisp functions? There is no explicit
prohibition, and many implementations do allow redefinition of
functions in the Lisp package.
CLtL only says that special forms can not be redefined. But this doesn't
solve the general problem of redefining system functions.
Proposal LISP-SYMBOL-REDEFINITION:MAR89-X3J13
Except where explicitly allowed, the consequences are undefined if any
of the following actions are performed on symbols in the COMMON-LISP
package:
1. Binding or altering its value (lexically or dynamically)
2. Defining or binding it as a function
3. Defining or binding it as a macro
4. Defining it as a type specifier (defstruct, defclass, deftype)
5. Defining it as a structure (defstruct)
6. Defining it as a declaration
7. Using it as a symbol macro
8. Altering its print name (this may already be prohibited)
9. Altering its package
10. Tracing it
11. Declaring or proclaiming it special or lexical
12. Declaring or proclaiming its type or ftype
13. Removing it from the package COMMON-LISP
If such a symbol is not globally defined as a variable or a constant,
it is allowed to lexically bind it and declare the type of that binding.
If such a symbol is not defined as a function, macro, or special form,
it is allowed to (lexically) bind it as a function and to declare the
ftype of that binding and to trace that binding.
If such a symbol is not defined as a function, macro, or special form,
it is allowed to (lexically) bind it as a macro.
Examples:
The behavior of the construct:
(FLET ((OPEN (filename &key direction) (format t "Open called....")
(OPEN filename :direction direction)))
(with-open-file (x "frob" :direction ':output)
(format t "was Open called?")))
is undefined; for example, the macro expansion of with-open-file might refer
to the OPEN function and might not.
(DEFUN CAR (X) (CDR X))
might signal an error.
Rationale:
This proposal is the only simple resolution of the problem description that
we can imagine that is consistent with current implementation techniques.
Allowing arbitrary redefinition of symbols in the system would place
severe restrictions on implementations not to actually use those symbols in
macro expansions of other symbols, in function calls, etc. While some
looser restrictions might do for any particular Common Lisp implementation,
there seems to be no good way to distinguish between those symbols that are
redefinable and those that are not.
In general, programs can redefine functions safely by creating new symbols in
their own package, possibly shadowing the name.
Current practice:
Many Lisp environments have some mechanism for warning about redefinition of
Lisp symbols and preventing accidental redefinition while allowing it where
necessary (e.g., to patch the Lisp system itself, fix a bug, add an
optimization.)
Fewer check for lexical redefinition, since such redefinition is not as
dangerous. Certainly, there are some symbols that are never used in macro
expansions of the standard Common Lisp macros. However, implementations do
differ on the behavior of macro expansions.
Cost to Implementors:
This proposal clarifies the status quo -- that the consequences are undefined. It
allows and encourages implementors to check for such redefinition, but does not
require it.
Cost to Users:
This proposal clarifies that implementations are free to check for a condition
that they might not have before, and may clarify that some current user code is
non-portable.
Benefits:
This issue frequently arises. Adopting this proposal would clarify a frequent
source of question about Common Lisp.
Cost of non-adoption:
Continued questions.
Esthetics:
Disallowing all redefinition is the simplest way of disallowing the ones that
really are trouble.
Discussion:
At the March 89 X3j13 meeting, a proposed additional constraint
("Altering its property list") was removed. Presumably this means
that conformal programs are allowed to alter the property list of
symbols in the COMMON-LISP package.
∂09-Apr-89 2239 CL-Cleanup-mailer Re: Issue: PACKAGE-FUNCTION-CONSISTENCY
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 9 Apr 89 22:39:02 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 09 APR 89 22:38:45 PDT
Date: 9 Apr 89 22:38 PDT
From: masinter.pa@Xerox.COM
Subject: Re: Issue: PACKAGE-FUNCTION-CONSISTENCY
In-reply-to: KMP%STONY-BROOK.SCRC.Symbolics:COM:Xerox's message of 4 Apr 89
12:31 PDT
To: KMP@Symbolics.COM
cc: CL-Cleanup@SAIL.Stanford.edu
Message-ID: <890409-223845-3466@Xerox>
I believe the status is that David mailed a Version 4 which contained the
correct wording for what was passed at the Jan 89 X3J13. I don't think we
need to discuss it again. I had it on the agenda because I knew my Version
3 was incorrect or cloudy.
I'm marking it "Passed, as amended, Jan 89 X3j13".
∂09-Apr-89 2248 CL-Cleanup-mailer Re: Issue: PATHNAME-CANONICAL-TYPE (Version 1)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 9 Apr 89 22:48:14 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 09 APR 89 22:48:13 PDT
Date: 9 Apr 89 22:47 PDT
From: masinter.pa@Xerox.COM
Subject: Re: Issue: PATHNAME-CANONICAL-TYPE (Version 1)
In-reply-to: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>'s message
of Wed, 23 Nov 88 18:55 EST
To: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
cc: CL-Cleanup@SAIL.STANFORD.EDU
Message-ID: <890409-224813-3470@Xerox>
You said:
"I have some concerns about your alternate proposal but my mind is not
closed. I need more time to study this alternative and would like to
postpone dealing with this issue until after the letter ballot, instead
targeting a mailing in time for an in-person vote in January.
"
I still like my alternative proposal, which is just a smaller,
but useful, subset.
∂09-Apr-89 2315 CL-Cleanup-mailer Re: PRETTY-PRINT-INTERFACE, version 4
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 9 Apr 89 23:15:32 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 09 APR 89 23:15:22 PDT
Date: 9 Apr 89 23:14 PDT
From: masinter.pa@Xerox.COM
Subject: Re: PRETTY-PRINT-INTERFACE, version 4
In-reply-to: dick@wheaties.ai.mit.edu's message of Wed, 22 Mar 89 13:54:34
EST
To: dick@wheaties.ai.mit.edu
cc: cl-cleanup@sail.stanford.edu
Message-ID: <890409-231522-3487@Xerox>
As I relayed to you, what I recall is that there was some squawking about
adding new FORMAT directives. Maybe we should break it up for voting.
∂09-Apr-89 2332 CL-Cleanup-mailer Issue: READ-DELIMITED-LIST-EOF
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 9 Apr 89 23:32:26 PDT
Received: from Salvador.ms by ArpaGateway.ms ; 09 APR 89 23:32:26 PDT
Date: 9 Apr 89 23:31 PDT
From: masinter.pa@Xerox.COM
Subject: Issue: READ-DELIMITED-LIST-EOF
To: KMP@symbolics.com
cc: cl-cleanup@sail.stanford.edu
Message-ID: <890409-233226-3497@Xerox>
This is what I have filed under "READ-DELIMITED-LIST-EOF".
I think this could well be handled under ERROR-CHECKING-IN-IO-CHAPTERS or
some such.
----- Begin Forwarded Messages -----
Date: Mon, 28 Nov 88 17:17 EST
From: Barry Margolin <barmar@Think.COM>
Subject: EOF during READ-DELIMITED-LIST
To: cl-cleanup@sail.stanford.edu
According to CLtL p.378, "it is always an error to hit end-of-file
during the operation of READ-DELIMITED-LIST." This makes
READ-DELIMITED-LIST almost useless, because it means that some user
input to an application can cause undefined effects.
I think that this particular "is an error" was not intended this way.
READ-DELIMITED-LIST should be the function that the standard "(" macro
character uses, and the latter is defined to signal an error if an EOF
occurs before the matching delimiter is read. Also, the previous
sentence says that this is the reason that there is no EOF-ERROR-P
argument; the implication is that READ-DELIMITED-LIST has an implicit
EOF-ERROR-P argument that is always non-NIL.
Has this already been cleaned up?
barmar
----- Next Message -----
Date: 29 Nov 88 14:45 PST
From: masinter.pa
Subject: Re: EOF during READ-DELIMITED-LIST
In-reply-to: Barry Margolin <barmar@Think.COM>'s message of Mon, 28 Nov 88
17:17 EST
To: Barry Margolin <barmar@Think.COM>
cc: masinter
As far as I know, there is no cleanup issue regarding READ-DELIMITED-LIST.
I think you might be proposing to change an "is an error" in CLtL into a
"signals an error"; if so, you might consider specifying the class of error
signalled.
----- End Forwarded Messages -----
∂10-Apr-89 0006 CL-Cleanup-mailer Re: Issue: TYPE-OF-UNDERCONSTRAINED
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 10 Apr 89 00:06:14 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 10 APR 89 00:05:53 PDT
Date: 10 Apr 89 00:05 PDT
From: masinter.pa@Xerox.COM
Subject: Re: Issue: TYPE-OF-UNDERCONSTRAINED
In-reply-to: KMP%STONY-BROOK.SCRC.Symbolics:COM:Xerox's message of 4 Apr 89
13:32 PDT
To: KMP@Symbolics.COM
cc: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <890410-000553-3516@Xerox>
Actually, Mary's notes and my recollection is that there was a motion to
reconsider that was tabled. I'm not sure this is the same as "no action was
tabled", but I think it definitely will come up next meeting.
∂10-Apr-89 0028 CL-Cleanup-mailer Cleanup Issue status, 10-Apr-89
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 10 Apr 89 00:28:23 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 10 APR 89 00:28:19 PDT
Date: 10 Apr 89 00:27 PDT
From: masinter.pa@Xerox.COM
Subject: Cleanup Issue status, 10-Apr-89
In-reply-to: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>'s message
of Thu, 6 Apr 89 14:14 EDT
To: CL-Cleanup@SAIL.Stanford.EDU, chapman%aitg.dec@decwrl.dec.com
line-fold: NO
Message-ID: <890410-002819-3553@Xerox>
Well, I had a couple of discrepancies, that I already sent mail
about, with Kent's notes. I think Mary has good notes this time,
and I checked them fairly carefully against mine.
Here's my issue status. Except for time-zone-non-integer,
I think I have updated versions of all passed
issues stored on arisia.xerox.com under the
clcleanup/passed
directory. The clcleanup/pending directory is unreliable.
Codes:
+ passed
* pending; to be considered later meeting
- withdrawn
released = "Mailed to X3J13@Sail.stanford.edu"
+ ADJUST-ARRAY-DISPLACEMENT
Version 4, 23-Nov-87
Status: passed, 1988
+ ADJUST-ARRAY-FILL-POINTER
Version 1, 15-MAR-88
Status: passed, 1988
+-* ADJUST-ARRAY-NOT-ADJUSTABLE
Synopsis: ADJUST-ARRAY on array made with :ADJUSTABLE NIL: "an error"?
Version 4, 11-Jan-89, Released 12-Jan-89
Status: Accepted with amendments Jan 89 X3J13
Comments: amendment had wording problem.
Version 9, 17-Mar-89, released 21-mar-89
Comments: still problems
Status: withdrawn Mar 89 X3J13, intend to revisit Jun 89 X3J13
+ APPLYHOOK-ENVIRONMENT
Synopsis: remove (useless) env argument to applyhook
Version 2, 10-Jan-89, Released 10-Jan-89
Status: Passed Jan-89 X3J13
+ AREF-1D
synopsis: add ROW-MAJOR-AREF
Version 7, 14-NOV-87
Status: Passed, 1988?
+ ARGUMENTS-UNDERSPECIFIED
Synopsis: Clarify various ranges missing from CLtL
Version 4, 21-Sep-88, Released 4 Dec 88
Status: Passed Jan 89 X3J13
+ ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS
Synopsis: What do array element-type declarations mean?
Version 9, 31-Oct-88, Released 5 Dec 88
Status: Passed Jan 89 X3J13
+ ASSOC-RASSOC-IF-KEY
Version 4, 23-NOV-87
Status: Passed, 1988?
+ BREAK-ON-WARNINGS-OBSOLETE
Synopsis: deprecate *BREAK-ON-WARNINGS* because of *BREAK-ON-SIGNALS*
Version 1, 07-Mar-89, Released 15-Mar-89
Version 2, 8-Apr-89, (not mailed, on arisia)
Status: Passed, as amended, Mar 89 X3J13
+ CLOS-CONDITIONS
Version 4, 10-Mar-89, released 16-Mar-89
Comments: define metaclass of conditions? Not here.
Status: Passed, Mar 89 X3J13
+ CLOSE-CONSTRUCTED-STREAMS
Synopsis: What does it mean to CLOSE a constructed stream?
Version 2, 12-Jan-89, Released 12-Jan-89
Status: Proposal ARGUMENT-STREAM-ONLY passed Jan 89 X3J13
+ CLOSED-STREAM-OPERATIONS
Synopsis: What operations are legal on closed streams?
Version 5, 5-Dec-88, released 5-Dec-88
Status: amended at Jan 89 X3J13; amendment withdrawn Mar 89 X3J13;
version 5 stands
- COERCE-INCOMPLETE
Synopsis: Extend COERCE
Version 3, 7-Mar-89, Released 14-Mar-89
Status: motion died for lack of second; withdrawn
+ COLON-NUMBER
Synopsis: :123 is an error
Version 1, 22-OCT-87
Status: Passed, 1988
+ COMMON-TYPE
Version 1, 20-Mar-89, released 21-Mar-89
Status: passed, Mar 89 X3J13
+ COMPLEX-RATIONAL-RESULT
Version 1, 20-Mar-89, released 21-Mar-89
Status: passed, Mar 89 X3J13
+ COMPILER-WARNING-STREAM
Version 6, 5-JUN-87
Status: Passed, 1988
+ COMPLEX-ATAN-BRANCH-CUT
Synopsis: tweak upper branch cut in ATAN formula
Version 1, 13-Dec-88, Released 10-Jan-89
Status: Passed Jan 89 X3J13
* CONDITION-RESTARTS
Synopsis: can't know whether restart is associated with signalling
Version 1, 18-Jan-89, released 16-Mar-89
Comment: (proposed amendments)
Status: need new version
+ CONTAGION-ON-NUMERICAL-COMPARISONS
Version 1, 14-Sep-88, Released 6 Oct 88
Status: passed, Jan 89 X3J13
+ COPY-SYMBOL-COPY-PLIST
Version 1, 10-Jan-89, released 16-Mar-89
Status: passed, Mar 89 X3j13
+ COPY-SYMBOL-PRINT-NAME
Version 2, 15-Mar-89, released 16-Mar-89
Status: passed, Mar 89 X3j13
+ DATA-TYPES-HIERARCHY-UNDERSPECIFIED
Version 2, 4-SEP-88, released 4-Sep-88
Status: Passed, Aug 88 X3J13
+ DECLARATION-SCOPE
Version 4, 15-Nov-88, Released 9-Dec-88
Status: NO-HOISTING passed Jan 89 X3J13
+ DECLARE-ARRAY-TYPE-ELEMENT-REFERENCES
Version 3, 13-Jan-89, released 3-Feb-89
Status: passed, Jan 89 X3J13
+ DECLARE-FUNCTION-AMBIGUITY
Version 4, 5-Dec-88, Released 5-Dec-88
Synopsis: (DECLARE (FUNCTION ...)) no longer synonym for FTYPE
Status: passed, Jan 89 X3J13
+ DECLARE-MACROS
Version 3, 5-FEB-88
Status: Passed, 1988?
+ DECLARE-TYPE-FREE
Version 10, 12-Jan-89
Status: proposal LEXICAL passed Jan 89 X3J13
+ DECODE-UNIVERSAL-TIME-DAYLIGHT
Version 2, 30-Sep-88, Released 6 Oct 88
Status: Passed, Jan 89 x3j13
+ DEFMACRO-LAMBDA-LIST
Version 3, 9-Apr-89, released 9-Apr-89
Status: Passed, as amended, Mar 89 X3J13
+ DEFPACKAGE
Version 7, 2-Nov-88, Released 5 Dec 88
Comment: clarify "at variance" in editorial work?
Status: Passed, Jan 89 X3J13
+ DEFSTRUCT-CONSTRUCTOR-KEY-MIXTURE
Version 3, 8-Jan-89, Released 11-Jan-89
Status: Passed, Jan 89 X3J13
+ DEFSTRUCT-DEFAULT-VALUE-EVALUATION
Version 1, 5/13/88
Status: Passed, 1988
+ DEFSTRUCT-PRINT-FUNCTION-INHERITANCE
Version 3, 7 Dec 88, Released 12-Dec-88
Status: Passed, Jan 89 X3J13
+ DEFSTRUCT-REDEFINITION
Synopsis: what happens if you redefine a DEFSTRUCT?
Version 1, 7/26/88, released 8-Oct-88
Version 3, 6-Feb-89 (not released, on arisia)
Status: Passed (as amended) Jan 89 X3J13
+ DEFSTRUCT-SLOTS-CONSTRAINTS-NAME
Version 5, 12-Jan-89
Status: Passed, Jan 89 X3J13
+ DEFSTRUCT-SLOTS-CONSTRAINTS-NUMBER
Version 1, 5/13/88
Status: Passed, 1988
+ DEFVAR-DOCUMENTATION
Version 2, 23-NOV-87
Status: Passed, 1988
+ DEFVAR-INIT-TIME
Version 2, 29-MAR-87
Status: Passed, 1988
+ DEFVAR-INITIALIZATION
Version 4 5-JUN-87
Status: Passed, 1988
+ DESCRIBE-INTERACTIVE
Version 4, 15-Nov-88, Released 7-Dec-88
Synopsis: can DESCRIBE ask user a question?
Status: Proposal NO passed Jan 89 X3J13
+ DESCRIBE-UNDERSPECIFIED
Version 1, 10-Mar-89, Released 16-Mar-89
Synopsis: making DESCRIBE generic was wrong; fix
Version 2, 9-Apr-89 (not released, on arisia)
status: passed, as amended, Mar 89 X3J13
+* DESTRUCTURING-BIND
Version 2, 25-Jan-89, Released 16-Mar-89
Synopsis: add DESTRUCTURING-BIND macro
Version 3, Mar 89, (Circulated at Mar 89 X3J13)
Status: passed, Mar 89 X3J13
*** NO VERSION ON ARISIA ***
* DIRECTORY-DOES-TO-MUCH
Version 1
Status: not on agenda, didn't get to; withdraw?
+ DISASSEMBLE-SIDE-EFFECT
Version 3 1/21/88
Status: Passed, 1988
+ DO-SYMBOLS-DUPLICATES
Version 3 23-NOV-87
Status: Passed, 1988
+ DOTTED-MACRO-FORMS
Version 3, 15-Nov-88, Released 7-Dec-88
Status: passed, Jan 89 X3J13
+ DRIBBLE-TECHNIQUE
Version 2, 14-FEB-88
Status: Passed, 1988
+ DYNAMIC-EXTENT
Version 3, 11-Jan-89, released 16-Mar-89
Version 4, 5-Apr-89, as amended (not released to X3j13, on arisia)
Status: passed, as amended, Mar 89 X3J13
* DYNAMIC-EXTENT-FUNCTION
Comment: spin-off of DYNAMIC-EXTENT, to be considered Jun 89
+ EQUAL-STRUCTURE
Version 6, 11-Jan-89, Released 12-Jan-89
Version 7, 15-Mar-89 (not released to X3j13, on arisia)
Status: Passed Jan 89 X3J13 as amended.
- EQUALP-GENERIC
Version 1, 28-Feb-89
Synopsis: make EQUALP generic function
Status: withdrawn, Mar 89 X3J13
* ERROR-CHECKING-IN-NUMBERS-CHAPTER
Version 1, 6-Mar-89
Synopsis: define 'should signal', 'might signal' for number fns
Status: to be considered Jun 89
- ERROR-NOT-HANDLED
Version 1, 25-Sep-88, Released 6-Oct-88 and 14-Mar-89
Status: withdrawn; made editorial advice
+ EVAL-OTHER
8-JUN-88, Version 2
Status: Passed, 1988?
+ EXIT-EXTENT
Version 6, 8-Jan-89, distributed Jan89 X3J13, Rereleased 16-Mar-89
Version 7, 4-Apr-89, as amended (not released to X3j13, on arisia)
Status: Passed, Mar 89 X3j13, as amended
+ EXPT-RATIO
Version 3, 31-Oct-88, Released 7 Dec 88
Status: passed, Jan 89 X3J13
+ FIXNUM-NON-PORTABLE
Version 4, 7-Dec-88, Released 12-Dec-88
Version 6, 17-Mar-89, as amended
Status: Passed, Jan 89 X3J13, as amended
+ FLET-DECLARATIONS
Version 2, 2 FEB 88
Status: Passed, 1988
+ FLET-IMPLICIT-BLOCK
Version 6, 5-JUN-87
Status: Passed, 1988
+ FORMAT-ATSIGN-COLON
Version 4, 5-JUN-87
Status: Passed, 1988
+ FORMAT-COLON-UPARROW-SCOPE
Version 3, 5 FEB 88
Status: Passed, 1988
+ FORMAT-COMMA-INTERVAL
Version 2, 15-JUN-87
Status: Passed, 1988
+ FORMAT-E-EXPONENT-SIGN
Version 2, 2 Oct 88, Released 6 Oct 88
Status: Passed, Jan 89 X3J13
+ FORMAT-OP-C
11-JUN-87, Version 5
Status: Passed, 1988
- FORMAT-PLURALS
Synopsis: remove ~P, add ~:@[singular~;plural~]
Status: not submitted, will not be considered
+ FORMAT-PRETTY-PRINT
Version 7, 15 Dec 88, Released 7 Dec 88
Comments: passed, Jan 89 X3j13
+ FUNCTION-CALL-EVALUATION-ORDER
Version 1, 22-MAR-88
Status: Passed, 1988
- FUNCTION-COERCE-TIME
Synopsis: When does SYMBOL-FUNCTION happen in MAPCAR?
Version 2, 16-sep-88, Released 8-Oct-88
Re-released: 16-Mar-89
Status: withdrawn; request editor to rewrite as explicitly vague
+ FUNCTION-COMPOSITION
Synopsis: Add new functions
Version 5, 10-Feb-89 (not released to X3j13; on arisia)
Status: Passed (as amended) Jan 89 X3J13
maybe this was passed as amendment to TEST-NOT-IF-NOT instead
+ FUNCTION-DEFINITION
Version 3, 10-Feb-89 (not released to X3J13, on arisia)
Status: Passed (as amended) Jan 89 X3J13
+ FUNCTION-NAME
Comment: renaming of SETF-FUNCTION-VS-MACRO, SETF-PLACES
Version 1, 27-Jan-89, Released 16-Mar-89
Status: FUNCTION-NAME:LARGE with sections 7, 8, and 9 removed, passed
Mar 89 X3J13
+ FUNCTION-TYPE
Version 12, 4-SEP-88, released 4-sep-88
Status: Passed, June 1988 X3J13, as amended
+ FUNCTION-TYPE-ARGUMENT-TYPE-SEMANTICS
Synopsis: Change semantics of argument types in function declarations
Version 3, 7-Dec-88, Released 12-Dec-88
Status: Passed, Jan 89 X3J13
+ FUNCTION-TYPE-KEY-NAME
Version 3, 13-FEB-88
Status: Passed, 1988
+ FUNCTION-TYPE-REST-LIST-ELEMENT
Version 5, 14-Nov-88, Released 8-Dec-88
Status: Passed, Jan 89 X3J13
+ GENSYM-NAME-STICKINESS
Synopsis: no side effects if optional arg supplied
Version 3, 20-Mar-89, Released 23-Mar-89
Status: passed, Mar 89 X3J13
+ GET-MACRO-CHARACTER-READTABLE
Version 3, 11-Feb-89 (not released; on arisia)
Status: Passed (as amended) Jan 89 X3J13
+ GET-SETF-METHOD-ENVIRONMENT
Version 5 13-JUL-87
Status: Passed, 1988
+ HASH-TABLE-ACCESS
Synopsis: Add new accessors for hash-table properties
Version 2, 13 Oct 88, released 16-Mar-89
Version 3, 5-Apr-89 (not released to X3j13; on arisia from KMP)
status: passed, as amended, Mar 89 X3J13
+ HASH-TABLE-PACKAGE-GENERATORS
Version 7, 8-Dec-88, Released 9-Dec-88
Comments: The test-package-iterator example has the values
from the generator in the wrong order.
Status: passed, Jan 89 X3J13
- HASH-TABLE-PRINTED-REPRESENTATION
Version 2, 8-Jun-88
Comments: Use #S(ARRAY ...), #S(HASH-TABLE...), #S(PATHNAME...)?
Status: didn't get to it; withdrawn
* HASH-TABLE-SIZE
Version 1, 20-Mar-89, released 21-Mar-89
Status: Postponed to Jun 89
+ HASH-TABLE-TESTS
Version 2, 8-Dec-88, Released 8 Dec 88
Status: passed Jan 89 X3J13
+ IEEE-ATAN-BRANCH-CUT
Version 2, 11-Jan-89, Released 11-Jan-89
Status: passed, Jan 89 X3J13
- IGNORE-VARIABLE
Synopsis: default (IGNORE IGNORE)
Version 1, 6-Feb-89
Status: didn't get to it by Mar 89; withdrawn
+ IMPORT-SETF-SYMBOL-PACKAGE
Version 5, MAY-87
Status: Passed, 1988?
+ IN-PACKAGE-FUNCTIONALITY
Version 8, 15-Mar-89, Released 15-Mar-89
Version 9, 9-Apr-89, as amended Mar89 X3J13, (not released, on Arisia)
Status: passed, as amended, Mar 89 X3J13
+ IN-SYNTAX
Version 3, 9-Apr-89 (not released, on Arisia)
Status: Version 2 (without cost/benefit analysis, but same proposal)
passed Mar 89 X3J13
+ KEYWORD-ARGUMENT-NAME-PACKAGE
Version 8, 8-NOV-87
Status: Passed, 1988?
+ LAST-N
12-MAR-88, Version 2
Status: Passed, 1988?
+ LCM-NO-ARGUMENTS
Version 1, 17 Oct 88, Released 8 Dec 88
Status: passed, Jan 89 X3J13
+ LISP-PACKAGE-NAME
Synopsis: change LISP to COMMON-LISP to avoid CLtL confusion
Version 1, 22 Dec 88, Released 11-Jan-89
Version 2, 9-Apr-89, as amended Mar 89 X3J13. Not released, on arisia
Status: passed, as amended, Mar 89 X3J13
+ LISP-SYMBOL-REDEFINITION
Version 5, 22-Nov-88, Released 8 Dec 88
Version 6, 9-Apr-89, as amended Mar 89 X3j13 (not released to X3j13, on arisia)
Status: passed, as amended, Mar 89 X3J13
+ LOAD-OBJECTS
Synopsis: Provide a way to allow defstruct/defclass objects in compiled files
Version 3, 9-Mar-89, released 16-Mar-89
Version 4, 4-Apr-89, (not released to X3J13, on arisia)
Status: passed, as amended, Mar 89 X3J13
* LOAD-TRUENAME
Synopsis: Make default pathname for LOAD inside LOAD same?
Version 1, 13-Mar-89, Released 16-Mar-89
Version 2 mailed, withdrawn. KMP has amendments
Status: postponed to Jun 89
+ LOCALLY-TOP-LEVEL
Version 2, 16-Mar-89, released 17-Mar-89
Status: passed, Mar 89 X3J13
+ LOOP-AND-DISCREPANCY
Version 1, 15-Mar-89, released 16-Mar-89
status: passed, Mar 89 X3J13
+ MACRO-FUNCTION-ENVIRONMENT
Version 2, 8-JUN-88
Status: Passed, 1988
- MACRO-SPECIAL-FORMS
Synopsis: macros => implementation-dependent special forms doesn't work
Status: didn't get to Mar 89; withdraw? ???
(LMM: I'm uneasy about withdrawning.)
+ MAKE-PACKAGE-USE-DEFAULT
Version 2, 8 Oct 88, Released 12-Dec-88
Version 3, 16-Mar-89
Status: Passed, Jan 89 X3J13 as amended
- MAKE-STRING-FILL-POINTER
Synopsis: extend MAKE-STRING to take a fill-pointer?
Version 1, 20-Oct-88, released 16-Mar-89
Status: withdrawn
+ MAPPING-DESTRUCTIVE-INTERACTION
Version 2, 09-Jun-88, Released 8 Oct 88
Synopsis: [don't] define interaction of DELETE on MAPCAR'd list.
Status: passed, Jan 89 X3J13
+ NTH-VALUE
Version 4, 8-Dec-88, Released 8 Dec 88
Comment: amended to clarify when index out of range
Version 5, 17-Mar-89 (not released; on arisia)
Status: passed, as amended, Jan 89 X3J13
+ PACKAGE-CLUTTER
Version 6, 12-Dec-88, Released 12-Dec-88
Comments: Accepted, with amendment
Version 7, 17-Mar-89 (not released; on arisia)
Status: Passed, Jan 89 X3J13, as amended
+ PACKAGE-DELETION
Version 5, 21 nov 88, Released 8 Dec 88
Status: passed, Jan 89 X3J13
+ PACKAGE-FUNCTION-CONSISTENCY
Synopsis: allow strings for package arg everywhere uniformly
Version 2, 12-Jan-89, Released 12-Jan-89
Version 4, 17-Mar-89, released 18-Mar-89
Status: passed, as amended, Jan 89 X3J13
* PATHNAME-CANONICAL-TYPE
Synopsis: allow canonical :SOURCE-LISP to MAKE-PATHNAME; add PATHNAME-CANONICAL-TYPE?
Version 1, 07-Jul-88
Status: postponed till Jun 89 X3J13
* PATHNAME-COMPONENT-CASE
Version 2, 22-Mar-89, released 22-Mar-89
Status: postponed till Jun 89 X3J13
* PATHNAME-COMPONENT-VALUE
Version 1, 20-Mar-89, released 21-Mar-89
Status: postponed till Jun 89 X3J13
* PATHNAME-EXTENSIONS
Version 1, 28-Dec-88
Status: ??? not discussed
* PATHNAME-LOGICAL
Synopsis: add logical pathnames (pathnames for an imaginary portable
file system, which get translated by site-dependent translations into
physical pathnames on an actual file system)
Status: no proposal yet
* PATHNAME-PRINT-READ
Synopsis: Print pathnames like #P"asdf"?
Version 1, 21-Oct-88, released 23-Mar-89
Status: postponed? Mar 89 to Thursday but not to Jun?
+ PATHNAME-STREAM
Version 6 14-NOV-87
Status: Passed, 1988
* PATHNAME-SUBDIRECTORY-LIST
Version 4, 22-Mar-89, released 22-mar-89 (Moon's version)
Status: Postponed to Jun 89 X3J13
+ PATHNAME-SYMBOL
Version 5 5-FEB-88
Status: Passed, 1988
* PATHNAME-SYNTAX-ERROR-TIME
Synopsis: when are errors in pathnames detected?
Version 1, 7-Jul-88, released 23-Mar-89
Comments: only want proposal PATHNAME-CREATION
Status: postponed to Jun 89 X3J13
+ PATHNAME-UNSPECIFIC-COMPONENT
Synopsis: More extensions to :UNSPECIFIC
Version 1, 29-Dec-88, Released 12-Jan-89
Version 2, 17-Mar-89 (not released, on arisia)
Status: Passed, Jan 89 X3j13, as amended
* PATHNAME-WILD
Version 2
Status: postponed to Jun 89
*+ PEEK-CHAR-READ-CHAR-ECHO
Version 3, 8-Oct-88, Released 8 Oct 88
Synopsis: PEEK-CHAR, READ-CHAR on streams made by MAKE-ECHO-STREAM
Status: Passed, Jan 89 X3J13
Kim Barrett wants to reopen
* PRETTY-PRINT-INTERFACE
Version 3, 15-Mar-89
Synopsis: standardize interface to prettyprinter
Status: postponed to Jun 89 X3J13
+ PRINC-CHARACTER
29-APR-87, Version 2
Status: Passed, 1988?
* PRINT-CASE-PRINT-ESCAPE-INTERACTION
Version 1, 26-Jan-89
Status: postponed tues -> thur; didn't get to. Revisit, probably
VERTICAL-BAR-RULE-NO-UPCASE
* PRINT-CIRCLE-SHARED
Synopsis: does *PRINT-CIRCLE* cause shared structure to print with #=?
Status: didn't get to; withdraw? revisit?
+ PRINT-CIRCLE-STRUCTURE
Version 3, 20 Sep 88, Released 8 Oct 88
Comments: Accepted, with amendment
Version 4, 17-Mar-89 (not released, on arisia)
Status: Passed, Jan 89 X3J13, as amended
- PROCLAIM-LEXICAL
Version 9, 8-Dec-88, Released 12-Dec-88
Synopsis: add LEXICAL proclaimation
Comments: lengthy mail; amendments at Jan meeting
Status: amended, then failed, Mar 89 X3J13
+ PUSH-EVALUATION-ORDER
Version 5, 25-NOV-87
Status: Passed, 1988
+ RANGE-OF-COUNT-KEYWORDS
Version 3, 9-Oct-88, Released 14-Oct-88
Status: passed, Jan 89 X3J13
+ RANGE-OF-START-AND-END-PARAMETERS
Version 1, 14-Sep-88, Released 7 Oct 88
Status: passed, Jan 89 X3J13
* READ-CASE-SENSITIVITY
Synopsis: Allow readtables to be case sensitive
Version 2, 23-Mar-89
Status: postponed to Jun 89; need one alternative
* READ-DELIMITED-LIST-EOF
Synopsis: eof in read deliminted list signals an error
Status: awaiting submission
+ REAL-NUMBER-TYPE
Synopsis: add REAL = (OR RATIONAL FLOAT) & range
Version 3, 13-Jan-89, released 16-Mar-89
Version 4, 5-Apr-89, as amended (not released, on arisia)
Status: passed, as amended, Mar 89 X3j13
+ REDUCE-ARGUMENT-EXTRACTION
Version 3 13-FEB-88
Status: Passed, 1988
+ REMF-DESTRUCTION-UNSPECIFIED
Synopsis: Specification of side-effect behavior in CL
Version 7, 5-Apr-89 (not released, as amended, on arisia)
Status: passed, as amended, Mar 89 X3J13
+ REQUIRE-PATHNAME-DEFAULTS
Version 6, 9 Dec 88, Released 09 Dec 88
Status: passed, Jan 89 X3j13
(Motion to retract failed Mar 89 X3J13)
+ REST-LIST-ALLOCATION
Version 3, 12-Dec-88, Released 12-Dec-88
Status: proposal MAY-SHARE passed, Jan 89 X3J13
+ RETURN-VALUES-UNSPECIFIED
Version 6, 9 Dec 88, Released 9-Dec-88
Status: passed, Jan 89 X3J13
+ ROOM-DEFAULT-ARGUMENT
Version 1, 12-Sep-88, Released 8 Oct 88
Status: passed, Jan 89 X3J13
* SETF-MULTIPLE-STORE-VARIABLES
Synopsis: Allow multiple "places" in SETF stores
Version 2, 22-Mar-89, released 22-Mar-89
Status: didn't get to Mar 89 X3J13.. withdraw?
+ SETF-SUB-METHODS
Version 5, 12-Feb-88, Released 8 Oct 88
Synopsis: careful definition of order inside (SETF (GETF ...) ...)
Status: passed, Jan 89 X3J13
+ SHADOW-ALREADY-PRESENT
Version 4 10-NOV-87
Status: Passed, 1988?
+ SHARPSIGN-PLUS-MINUS-PACKAGE
Version 3 14-NOV-87
Status: Passed, 1988?
+ SPECIAL-TYPE-SHADOWING
Synopsis: intersection of types when proclaimed special has local type
declaration
Version 1, 4-Nov-88, released 11-Jan-89
Status: passed, Jan 89 X3J13
+ STANDARD-INPUT-INITIAL-BINDING
Version 8, 8 Jul 88, Released 7 Oct 88
Status: passed, Jan 89 X3J13
+ STEP-ENVIRONMENT
Version 3, 20-Jun-88, Released 7 Oct 88
Version 4, 17-Mar-89
status: Passed, Jan 89 X3J13, as amended
+ STREAM-ACCESS
Version 2, 30-Nov-88, Released 9 Dec 88
Status: ADD-TYPES-ACCESSORS passed, Jan 89 X3J13
* STREAM-DEFINITION-BY-USER
Version 1, 22-Mar-89, Released hardcopy Mar 89 X3J13
Comments: Cleanup forum? For 'future directions'?
+ SUBSEQ-OUT-OF-BOUNDS
29-MAR-88 Version 2
Status: Passed, 1988?
- SUBTYPEP-ENVIRONMENT
Version 1, 2-Jan-89
Status: missing writeup, didn't get to, withdraw
+ SUBTYPEP-TOO-VAGUE
Version 4, 7-Oct-88, Released 7 Oct 88
Status: passed, Jan 89 X3J13
+ SYMBOL-MACROLET-DECLARE
Version 2, 9-Dec-88, Released 9 Dec 88
Status: passed, Jan 89 X3J13
+ SYMBOL-MACROLET-SEMANTICS
Status: Version 5, Passed, Jan 89 X3J13
Version 6, 14-Mar-89, released 16-Mar-89
Status: Version 6 (reconsidered), passed, Mar 89 X3J13
+ TAILP-NIL
Version 5, 9-Dec-88, Released 12-Dec-88
Synopsis: Operation of TAILP given NIL
Status: passed, Jan 89 X3J13
+ TEST-NOT-IF-NOT
Version 3, 1 Dec 88, Released 9 dec
Version 4, 18-Mar-89
Status: Need new version as amended.
* THE-AMBIGUITY
Version 2, 11-Jan-89, Released 11-Jan-89
Comments: typo, sense wrong
Status: didn't come up Mar 89 X3J13; withdraw?
+ TIME-ZONE-NON-INTEGER
Version 1, 13-Mar-89, Released 16-Mar-89
Status: passed with amendments; *** NEED VERSION AS AMENDED ****
* TYPE-OF-UNDERCONSTRAINED
Version 3, 12-Dec-88, Released 12 Dec 88
Comments: Accepted, with amendments
Version 5, 16-Mar-89
Comments: Moon's comments, only some responses. Fix
Status: ** NEED NEW VERSION ***
* UNDEFINED-VARIABLES-AND-FUNCTIONS
Synopsis: What happens on an undefined function call, unbound variable ref?
Version 1, 29-Nov-88, Released 11-Jan-89
Comments: offline discussion about SLOT-UNBOUND
Status: vote on 1?
+ UNREAD-CHAR-AFTER-PEEK-CHAR
Version 2, 2-Dec-88, Released 12-Dec-88
Status: passed, Jan 89 X3J13
+ VARIABLE-LIST-ASYMMETRY
Version 3, 08-Oct-88, Released 9 Dec 88
Status: passed, Jan 89 X3J13
+ WITH-OUTPUT-TO-STRING-APPEND-STYLE
Version 5, 7-JUN-88
Status: Passed, 1988
* WITH-OPEN-FILE-DOES-NOT-EXIST
Version 1, 17-Mar-89
Status: didn't get to; withdraw?
∂10-Apr-89 1025 CL-Cleanup-mailer Cleanup Issue status, 10-Apr-89
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 10 Apr 89 10:25:20 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 10 APR 89 09:56:10 PDT
Date: 10 Apr 89 09:52 PDT
From: masinter.pa@Xerox.COM
Subject: Cleanup Issue status, 10-Apr-89
To: cl-cleanup@Sail.stanford.edu
Message-ID: <890410-095610-4389@Xerox>
Here's my revised issue status.
I think I have updated versions of all passed
issues stored on arisia.xerox.com under the
clcleanup/passed
directory. The clcleanup/pending directory is unreliable.
Do you think we need to mail the 'unreleased' versions to
X3J13?
!
Codes:
+ passed
* pending; to be considered later meeting
- withdrawn
released = "Mailed to X3J13@Sail.stanford.edu"
+ ADJUST-ARRAY-DISPLACEMENT
Version 4, 23-Nov-87
Status: passed, 1988
+ ADJUST-ARRAY-FILL-POINTER
Version 1, 15-MAR-88
Status: passed, 1988
+-* ADJUST-ARRAY-NOT-ADJUSTABLE
Synopsis: ADJUST-ARRAY on array made with :ADJUSTABLE NIL: "an error"?
Version 4, 11-Jan-89, Released 12-Jan-89
Status: Accepted with amendments Jan 89 X3J13
Comments: amendment had wording problem.
Version 9, 17-Mar-89, released 21-mar-89
Comments: still problems
Status: withdrawn Mar 89 X3J13, intend to revisit Jun 89 X3J13
+ APPLYHOOK-ENVIRONMENT
Synopsis: remove (useless) env argument to applyhook
Version 2, 10-Jan-89, Released 10-Jan-89
Status: Passed Jan-89 X3J13
+ AREF-1D
synopsis: add ROW-MAJOR-AREF
Version 7, 14-NOV-87
Status: Passed, 1988
+ ARGUMENTS-UNDERSPECIFIED
Synopsis: Clarify various ranges missing from CLtL
Version 4, 21-Sep-88, Released 4 Dec 88
Status: Passed Jan 89 X3J13
+ ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS
Synopsis: What do array element-type declarations mean?
Version 9, 31-Oct-88, Released 5 Dec 88
Status: Passed Jan 89 X3J13
+ ASSOC-RASSOC-IF-KEY
Version 4, 23-NOV-87
Status: Passed, 1988
+ BREAK-ON-WARNINGS-OBSOLETE
Synopsis: deprecate *BREAK-ON-WARNINGS* because of *BREAK-ON-SIGNALS*
Version 1, 07-Mar-89, Released 15-Mar-89
Version 2, 8-Apr-89, (not mailed, on arisia)
Status: Passed, as amended, Mar 89 X3J13
+ CLOS-CONDITIONS
Version 4, 10-Mar-89, released 16-Mar-89
Comments: define metaclass of conditions? Not here.
Status: Passed, Mar 89 X3J13
+ CLOSE-CONSTRUCTED-STREAMS
Synopsis: What does it mean to CLOSE a constructed stream?
Version 2, 12-Jan-89, Released 12-Jan-89
Status: Proposal ARGUMENT-STREAM-ONLY passed Jan 89 X3J13
+ CLOSED-STREAM-OPERATIONS
Synopsis: What operations are legal on closed streams?
Version 5, 5-Dec-88, released 5-Dec-88
Status: amended at Jan 89 X3J13; amendment withdrawn Mar 89 X3J13;
version 5 stands
- COERCE-INCOMPLETE
Synopsis: Extend COERCE
Version 3, 7-Mar-89, Released 14-Mar-89
Status: motion died for lack of second; withdrawn
+ COLON-NUMBER
Synopsis: :123 is an error
Version 1, 22-OCT-87
Status: Passed, 1988
+ COMMON-TYPE
Version 1, 20-Mar-89, released 21-Mar-89
Status: passed, Mar 89 X3J13
+ COMPLEX-RATIONAL-RESULT
Version 1, 20-Mar-89, released 21-Mar-89
Status: passed, Mar 89 X3J13
+ COMPILER-WARNING-STREAM
Version 6, 5-JUN-87
Status: Passed, 1988
+ COMPLEX-ATAN-BRANCH-CUT
Synopsis: tweak upper branch cut in ATAN formula
Version 1, 13-Dec-88, Released 10-Jan-89
Status: Passed Jan 89 X3J13
* CONDITION-RESTARTS
Synopsis: can't know whether restart is associated with signalling
Version 1, 18-Jan-89, released 16-Mar-89
Comment: (proposed amendments)
Status: need new version
+ CONTAGION-ON-NUMERICAL-COMPARISONS
Version 1, 14-Sep-88, Released 6 Oct 88
Status: passed, Jan 89 X3J13
+ COPY-SYMBOL-COPY-PLIST
Version 1, 10-Jan-89, released 16-Mar-89
Status: passed, Mar 89 X3j13
+ COPY-SYMBOL-PRINT-NAME
Version 2, 15-Mar-89, released 16-Mar-89
Status: passed, Mar 89 X3j13
+ DATA-TYPES-HIERARCHY-UNDERSPECIFIED
Version 2, 4-SEP-88, released 4-Sep-88
Status: Passed, Aug 88 X3J13
+ DECLARATION-SCOPE
Version 4, 15-Nov-88, Released 9-Dec-88
Status: NO-HOISTING passed Jan 89 X3J13
+ DECLARE-ARRAY-TYPE-ELEMENT-REFERENCES
Version 3, 13-Jan-89, released 3-Feb-89
Status: passed, Jan 89 X3J13
+ DECLARE-FUNCTION-AMBIGUITY
Version 4, 5-Dec-88, Released 5-Dec-88
Synopsis: (DECLARE (FUNCTION ...)) no longer synonym for FTYPE
Status: passed, Jan 89 X3J13
+ DECLARE-MACROS
Version 3, 5-FEB-88
Status: Passed, 1988?
+ DECLARE-TYPE-FREE
Version 10, 12-Jan-89
Status: proposal LEXICAL passed Jan 89 X3J13
+ DECODE-UNIVERSAL-TIME-DAYLIGHT
Version 2, 30-Sep-88, Released 6 Oct 88
Status: Passed, Jan 89 x3j13
+ DEFMACRO-LAMBDA-LIST
Version 3, 9-Apr-89, released 9-Apr-89 (as amended)
Version 4, 10-Apr-89 (left out an amendment; not released)
Status: Passed, as amended, Mar 89 X3J13
+ DEFPACKAGE
Version 7, 2-Nov-88, Released 5 Dec 88
Comment: clarify "at variance" in editorial work?
Status: Passed, Jan 89 X3J13
+ DEFSTRUCT-CONSTRUCTOR-KEY-MIXTURE
Version 3, 8-Jan-89, Released 11-Jan-89
Status: Passed, Jan 89 X3J13
+ DEFSTRUCT-DEFAULT-VALUE-EVALUATION
Version 1, 5/13/88
Status: Passed, 1988
+ DEFSTRUCT-PRINT-FUNCTION-INHERITANCE
Version 3, 7 Dec 88, Released 12-Dec-88
Status: Passed, Jan 89 X3J13
+ DEFSTRUCT-REDEFINITION
Synopsis: what happens if you redefine a DEFSTRUCT?
Version 1, 7/26/88, released 8-Oct-88
Version 3, 6-Feb-89 (not released, on arisia)
Status: Passed (as amended) Jan 89 X3J13
+ DEFSTRUCT-SLOTS-CONSTRAINTS-NAME
Version 5, 12-Jan-89
Status: Passed, Jan 89 X3J13
+ DEFSTRUCT-SLOTS-CONSTRAINTS-NUMBER
Version 1, 5/13/88
Status: Passed, 1988
+ DEFVAR-DOCUMENTATION
Version 2, 23-NOV-87
Status: Passed, 1988
+ DEFVAR-INIT-TIME
Version 2, 29-MAR-87
Status: Passed, 1988
+ DEFVAR-INITIALIZATION
Version 4 5-JUN-87
Status: Passed, 1988
+ DESCRIBE-INTERACTIVE
Version 4, 15-Nov-88, Released 7-Dec-88
Synopsis: can DESCRIBE ask user a question?
Status: Proposal NO passed Jan 89 X3J13
+ DESCRIBE-UNDERSPECIFIED
Version 1, 10-Mar-89, Released 16-Mar-89
Synopsis: making DESCRIBE generic was wrong; fix
Version 2, 9-Apr-89 (not released, on arisia)
status: passed, as amended, Mar 89 X3J13
+ DESTRUCTURING-BIND
Version 2, 25-Jan-89, Released 16-Mar-89
Synopsis: add DESTRUCTURING-BIND macro
Version 3, Mar 89, (circulated at Mar 89 X3J13, not released, on arisia)
Status: passed, Mar 89 X3J13
* DIRECTORY-DOES-TO-MUCH
Version 1
Status: not on agenda, didn't get to; withdraw?
+ DISASSEMBLE-SIDE-EFFECT
Version 3 1/21/88
Status: Passed, 1988
+ DO-SYMBOLS-DUPLICATES
Version 3 23-NOV-87
Status: Passed, 1988
+ DOTTED-MACRO-FORMS
Version 3, 15-Nov-88, Released 7-Dec-88
Status: passed, Jan 89 X3J13
+ DRIBBLE-TECHNIQUE
Version 2, 14-FEB-88
Status: Passed, 1988
+ DYNAMIC-EXTENT
Version 3, 11-Jan-89, released 16-Mar-89
Version 4, 5-Apr-89, as amended (not released to X3j13, on arisia)
Status: passed, as amended, Mar 89 X3J13
* DYNAMIC-EXTENT-FUNCTION
Comment: spin-off of DYNAMIC-EXTENT, to be considered Jun 89
Version 1, 4-Apr-89
- ENVIRONMENT-ENQUIRY
Synopsis: "The environment inquiry functions (pp447-448) don't return a
value in consistent format across implementations. This makes
them virtually useless. I would like to constrain the values
enough so that implementors knew what to provide as return
values, and provide some examples of intended uses."
Status: didn't get to; withdrawn
+ EQUAL-STRUCTURE
Version 6, 11-Jan-89, Released 12-Jan-89
Version 7, 15-Mar-89 (not released to X3j13, on arisia)
Status: Passed Jan 89 X3J13 as amended.
- EQUALP-GENERIC
Version 1, 28-Feb-89
Synopsis: make EQUALP generic function
Status: withdrawn, Mar 89 X3J13
* ERROR-CHECKING-IN-NUMBERS-CHAPTER
Version 1, 6-Mar-89
Synopsis: define 'should signal', 'might signal' for number fns
Status: to be considered Jun 89
- ERROR-NOT-HANDLED
Version 1, 25-Sep-88, Released 6-Oct-88 and 14-Mar-89
Status: withdrawn; made editorial advice
+ EVAL-OTHER
8-JUN-88, Version 2
Status: Passed, 1988?
+ EXIT-EXTENT
Version 6, 8-Jan-89, distributed Jan89 X3J13, Rereleased 16-Mar-89
Version 7, 4-Apr-89, as amended (not released to X3j13, on arisia)
Status: Passed, Mar 89 X3j13, as amended
+ EXPT-RATIO
Version 3, 31-Oct-88, Released 7 Dec 88
Status: passed, Jan 89 X3J13
+ FIXNUM-NON-PORTABLE
Version 4, 7-Dec-88, Released 12-Dec-88
Version 6, 17-Mar-89, as amended
Status: Passed, Jan 89 X3J13, as amended
+ FLET-DECLARATIONS
Version 2, 2 FEB 88
Status: Passed, 1988
+ FLET-IMPLICIT-BLOCK
Version 6, 5-JUN-87
Status: Passed, 1988
+ FORMAT-ATSIGN-COLON
Version 4, 5-JUN-87
Status: Passed, 1988
+ FORMAT-COLON-UPARROW-SCOPE
Version 3, 5 FEB 88
Status: Passed, 1988
+ FORMAT-COMMA-INTERVAL
Version 2, 15-JUN-87
Status: Passed, 1988
+ FORMAT-E-EXPONENT-SIGN
Version 2, 2 Oct 88, Released 6 Oct 88
Status: Passed, Jan 89 X3J13
+ FORMAT-OP-C
11-JUN-87, Version 5
Status: Passed, 1988
- FORMAT-PLURALS
Synopsis: remove ~P, add ~:@[singular~;plural~]
Status: not submitted, will not be considered
+ FORMAT-PRETTY-PRINT
Version 7, 15 Dec 88, Released 7 Dec 88
Comments: passed, Jan 89 X3j13
+ FUNCTION-CALL-EVALUATION-ORDER
Version 1, 22-MAR-88
Status: Passed, 1988
- FUNCTION-COERCE-TIME
Synopsis: When does SYMBOL-FUNCTION happen in MAPCAR?
Version 2, 16-sep-88, Released 8-Oct-88
Re-released: 16-Mar-89
Status: withdrawn; request editor to rewrite as explicitly vague
+ FUNCTION-COMPOSITION
Synopsis: Add new functions
Version 5, 10-Feb-89 (not released to X3j13; on arisia)
Status: Passed (as amended) Jan 89 X3J13
maybe this was passed as amendment to TEST-NOT-IF-NOT instead
+ FUNCTION-DEFINITION
Version 3, 10-Feb-89 (not released to X3J13, on arisia)
Status: Passed (as amended) Jan 89 X3J13
+ FUNCTION-NAME
Comment: renaming of SETF-FUNCTION-VS-MACRO, SETF-PLACES
Version 1, 27-Jan-89, Released 16-Mar-89
Status: FUNCTION-NAME:LARGE with sections 7, 8, and 9 removed, passed
Mar 89 X3J13
+ FUNCTION-TYPE
Version 12, 4-SEP-88, released 4-sep-88
Status: Passed, June 1988 X3J13, as amended
+ FUNCTION-TYPE-ARGUMENT-TYPE-SEMANTICS
Synopsis: Change semantics of argument types in function declarations
Version 3, 7-Dec-88, Released 12-Dec-88
Status: Passed, Jan 89 X3J13
+ FUNCTION-TYPE-KEY-NAME
Version 3, 13-FEB-88
Status: Passed, 1988
+ FUNCTION-TYPE-REST-LIST-ELEMENT
Version 5, 14-Nov-88, Released 8-Dec-88
Status: Passed, Jan 89 X3J13
+ GENSYM-NAME-STICKINESS
Synopsis: no side effects if optional arg supplied
Version 3, 20-Mar-89, Released 23-Mar-89
Status: passed, Mar 89 X3J13
+ GET-MACRO-CHARACTER-READTABLE
Version 3, 11-Feb-89 (not released; on arisia)
Status: Passed (as amended) Jan 89 X3J13
+ GET-SETF-METHOD-ENVIRONMENT
Version 5 13-JUL-87
Status: Passed, 1988
+ HASH-TABLE-ACCESS
Synopsis: Add new accessors for hash-table properties
Version 2, 13 Oct 88, released 16-Mar-89
Version 3, 5-Apr-89 (not released to X3j13; on arisia from KMP)
status: passed, as amended, Mar 89 X3J13
+ HASH-TABLE-PACKAGE-GENERATORS
Version 7, 8-Dec-88, Released 9-Dec-88
Comments: The test-package-iterator example has the values
from the generator in the wrong order.
Status: passed, Jan 89 X3J13
- HASH-TABLE-PRINTED-REPRESENTATION
Version 2, 8-Jun-88
Comments: Use #S(ARRAY ...), #S(HASH-TABLE...), #S(PATHNAME...)?
Status: didn't get to it; withdrawn
* HASH-TABLE-SIZE
Version 1, 20-Mar-89, released 21-Mar-89
Status: Postponed to Jun 89
+ HASH-TABLE-TESTS
Version 2, 8-Dec-88, Released 8 Dec 88
Status: passed Jan 89 X3J13
+ IEEE-ATAN-BRANCH-CUT
Version 2, 11-Jan-89, Released 11-Jan-89
Status: passed, Jan 89 X3J13
- IGNORE-VARIABLE
Synopsis: default (IGNORE IGNORE)
Version 1, 6-Feb-89
Status: didn't get to it by Mar 89; withdrawn
+ IMPORT-SETF-SYMBOL-PACKAGE
Version 5, MAY-87
Status: Passed, 1988?
+ IN-PACKAGE-FUNCTIONALITY
Version 8, 15-Mar-89, Released 15-Mar-89
Version 9, 9-Apr-89, as amended Mar89 X3J13, (not released, on Arisia)
Status: passed, as amended, Mar 89 X3J13
+ IN-SYNTAX
Version 3, 9-Apr-89 (not released, on Arisia)
Status: Version 2 (without cost/benefit analysis, but same proposal)
passed Mar 89 X3J13
+ KEYWORD-ARGUMENT-NAME-PACKAGE
Version 8, 8-NOV-87
Status: Passed, 1988?
+ LAST-N
12-MAR-88, Version 2
Status: Passed, 1988?
+ LCM-NO-ARGUMENTS
Version 1, 17 Oct 88, Released 8 Dec 88
Status: passed, Jan 89 X3J13
+ LISP-PACKAGE-NAME
Synopsis: change LISP to COMMON-LISP to avoid CLtL confusion
Version 1, 22 Dec 88, Released 11-Jan-89
Version 2, 9-Apr-89, as amended Mar 89 X3J13. Not released, on arisia
Status: passed, as amended, Mar 89 X3J13
+ LISP-SYMBOL-REDEFINITION
Version 5, 22-Nov-88, Released 8 Dec 88
Version 6, 9-Apr-89, as amended Mar 89 X3j13 (not released to X3j13, on arisia)
Status: passed, as amended, Mar 89 X3J13
+ LOAD-OBJECTS
Synopsis: Provide a way to allow defstruct/defclass objects in compiled files
Version 3, 9-Mar-89, released 16-Mar-89
Version 4, 4-Apr-89, (not released to X3J13, on arisia)
Status: passed, as amended, Mar 89 X3J13
* LOAD-TRUENAME
Synopsis: Make default pathname for LOAD inside LOAD same?
Version 1, 13-Mar-89, Released 16-Mar-89
Version 2 mailed, withdrawn. KMP has amendments
Status: postponed to Jun 89
+ LOCALLY-TOP-LEVEL
Version 2, 16-Mar-89, released 17-Mar-89
Status: passed, Mar 89 X3J13
+ LOOP-AND-DISCREPANCY
Version 1, 15-Mar-89, released 16-Mar-89
status: passed, Mar 89 X3J13
+ MACRO-FUNCTION-ENVIRONMENT
Version 2, 8-JUN-88
Status: Passed, 1988
- MACRO-SPECIAL-FORMS
Synopsis: macros => implementation-dependent special forms doesn't work
Status: didn't get to Mar 89; withdraw? ???
(LMM: I'm uneasy about withdrawning.)
+ MAKE-PACKAGE-USE-DEFAULT
Version 2, 8 Oct 88, Released 12-Dec-88
Version 3, 16-Mar-89
Status: Passed, Jan 89 X3J13 as amended
- MAKE-STRING-FILL-POINTER
Synopsis: extend MAKE-STRING to take a fill-pointer?
Version 1, 20-Oct-88, released 16-Mar-89
Status: withdrawn
+ MAPPING-DESTRUCTIVE-INTERACTION
Version 2, 09-Jun-88, Released 8 Oct 88
Synopsis: [don't] define interaction of DELETE on MAPCAR'd list.
Status: passed, Jan 89 X3J13
+ NTH-VALUE
Version 4, 8-Dec-88, Released 8 Dec 88
Comment: amended to clarify when index out of range
Version 5, 17-Mar-89 (not released; on arisia)
Status: passed, as amended, Jan 89 X3J13
+ PACKAGE-CLUTTER
Version 6, 12-Dec-88, Released 12-Dec-88
Comments: Accepted, with amendment
Version 7, 17-Mar-89 (not released; on arisia)
Status: Passed, Jan 89 X3J13, as amended
+ PACKAGE-DELETION
Version 5, 21 nov 88, Released 8 Dec 88
Status: passed, Jan 89 X3J13
+ PACKAGE-FUNCTION-CONSISTENCY
Synopsis: allow strings for package arg everywhere uniformly
Version 2, 12-Jan-89, Released 12-Jan-89
Version 4, 17-Mar-89, released 18-Mar-89
Status: passed, as amended, Jan 89 X3J13
* PATHNAME-CANONICAL-TYPE
Synopsis: allow canonical :SOURCE-LISP to MAKE-PATHNAME; add PATHNAME-CANONICAL-TYPE?
Version 1, 07-Jul-88
Status: postponed till Jun 89 X3J13
* PATHNAME-COMPONENT-CASE
Version 2, 22-Mar-89, released 22-Mar-89
Status: postponed till Jun 89 X3J13
* PATHNAME-COMPONENT-VALUE
Version 1, 20-Mar-89, released 21-Mar-89
Status: postponed till Jun 89 X3J13
* PATHNAME-EXTENSIONS
Version 1, 28-Dec-88
Status: ??? not discussed
* PATHNAME-LOGICAL
Synopsis: add logical pathnames (pathnames for an imaginary portable
file system, which get translated by site-dependent translations into
physical pathnames on an actual file system)
Status: no proposal yet
* PATHNAME-PRINT-READ
Synopsis: Print pathnames like #P"asdf"?
Version 1, 21-Oct-88, released 23-Mar-89
Status: postponed? Mar 89 to Thursday but not to Jun?
+ PATHNAME-STREAM
Version 6 14-NOV-87
Status: Passed, 1988
* PATHNAME-SUBDIRECTORY-LIST
Version 4, 22-Mar-89, released 22-mar-89 (Moon's version)
Status: Postponed to Jun 89 X3J13
+ PATHNAME-SYMBOL
Version 5 5-FEB-88
Status: Passed, 1988
* PATHNAME-SYNTAX-ERROR-TIME
Synopsis: when are errors in pathnames detected?
Version 1, 7-Jul-88, released 23-Mar-89
Comments: only want proposal PATHNAME-CREATION
Status: postponed to Jun 89 X3J13
+ PATHNAME-UNSPECIFIC-COMPONENT
Synopsis: More extensions to :UNSPECIFIC
Version 1, 29-Dec-88, Released 12-Jan-89
Version 2, 17-Mar-89 (not released, on arisia)
Status: Passed, Jan 89 X3j13, as amended
* PATHNAME-WILD
Version 2
Status: postponed to Jun 89
*+ PEEK-CHAR-READ-CHAR-ECHO
Version 3, 8-Oct-88, Released 8 Oct 88
Synopsis: PEEK-CHAR, READ-CHAR on streams made by MAKE-ECHO-STREAM
Status: Passed, Jan 89 X3J13
Kim Barrett wants to reopen
* PRETTY-PRINT-INTERFACE
Version 3, 15-Mar-89
Synopsis: standardize interface to prettyprinter
Status: postponed to Jun 89 X3J13
+ PRINC-CHARACTER
29-APR-87, Version 2
Status: Passed, 1988?
* PRINT-CASE-PRINT-ESCAPE-INTERACTION
Version 1, 26-Jan-89
Status: postponed tues -> thur; didn't get to. Revisit, probably
VERTICAL-BAR-RULE-NO-UPCASE
* PRINT-CIRCLE-SHARED
Synopsis: does *PRINT-CIRCLE* cause shared structure to print with #=?
Status: didn't get to; withdraw? revisit?
+ PRINT-CIRCLE-STRUCTURE
Version 3, 20 Sep 88, Released 8 Oct 88
Comments: Accepted, with amendment
Version 4, 17-Mar-89 (not released, on arisia)
Status: Passed, Jan 89 X3J13, as amended
- PROCLAIM-LEXICAL
Version 9, 8-Dec-88, Released 12-Dec-88
Synopsis: add LEXICAL proclaimation
Comments: lengthy mail; amendments at Jan meeting
Status: amended, then failed, Mar 89 X3J13
+ PUSH-EVALUATION-ORDER
Version 5, 25-NOV-87
Status: Passed, 1988
+ RANGE-OF-COUNT-KEYWORDS
Version 3, 9-Oct-88, Released 14-Oct-88
Status: passed, Jan 89 X3J13
+ RANGE-OF-START-AND-END-PARAMETERS
Version 1, 14-Sep-88, Released 7 Oct 88
Status: passed, Jan 89 X3J13
* READ-CASE-SENSITIVITY
Synopsis: Allow readtables to be case sensitive
Version 2, 23-Mar-89
Status: postponed to Jun 89; need one alternative
* READ-DELIMITED-LIST-EOF
Synopsis: eof in read deliminted list signals an error
Status: awaiting submission
+ REAL-NUMBER-TYPE
Synopsis: add REAL = (OR RATIONAL FLOAT) & range
Version 3, 13-Jan-89, released 16-Mar-89
Version 4, 5-Apr-89, as amended (not released, on arisia)
Status: passed, as amended, Mar 89 X3j13
+ REDUCE-ARGUMENT-EXTRACTION
Version 3 13-FEB-88
Status: Passed, 1988
+ REMF-DESTRUCTION-UNSPECIFIED
Synopsis: Specification of side-effect behavior in CL
Version 7, 5-Apr-89 (not released, as amended, on arisia)
Status: passed, as amended, Mar 89 X3J13
+ REQUIRE-PATHNAME-DEFAULTS
Version 6, 9 Dec 88, Released 09 Dec 88
Status: passed, Jan 89 X3j13
(Motion to retract failed Mar 89 X3J13)
+ REST-LIST-ALLOCATION
Version 3, 12-Dec-88, Released 12-Dec-88
Status: proposal MAY-SHARE passed, Jan 89 X3J13
+ RETURN-VALUES-UNSPECIFIED
Version 6, 9 Dec 88, Released 9-Dec-88
Status: passed, Jan 89 X3J13
+ ROOM-DEFAULT-ARGUMENT
Version 1, 12-Sep-88, Released 8 Oct 88
Status: passed, Jan 89 X3J13
* SETF-MULTIPLE-STORE-VARIABLES
Synopsis: Allow multiple "places" in SETF stores
Version 2, 22-Mar-89, released 22-Mar-89
Status: didn't get to Mar 89 X3J13.. withdraw?
+ SETF-SUB-METHODS
Version 5, 12-Feb-88, Released 8 Oct 88
Synopsis: careful definition of order inside (SETF (GETF ...) ...)
Status: passed, Jan 89 X3J13
+ SHADOW-ALREADY-PRESENT
Version 4 10-NOV-87
Status: Passed, 1988?
+ SHARPSIGN-PLUS-MINUS-PACKAGE
Version 3 14-NOV-87
Status: Passed, 1988?
+ SPECIAL-TYPE-SHADOWING
Synopsis: intersection of types when proclaimed special has local type
declaration
Version 1, 4-Nov-88, released 11-Jan-89
Status: passed, Jan 89 X3J13
+ STANDARD-INPUT-INITIAL-BINDING
Version 8, 8 Jul 88, Released 7 Oct 88
Status: passed, Jan 89 X3J13
+ STEP-ENVIRONMENT
Version 3, 20-Jun-88, Released 7 Oct 88
Version 4, 17-Mar-89
status: Passed, Jan 89 X3J13, as amended
+ STREAM-ACCESS
Version 2, 30-Nov-88, Released 9 Dec 88
Status: ADD-TYPES-ACCESSORS passed, Jan 89 X3J13
* STREAM-DEFINITION-BY-USER
Version 1, 22-Mar-89, Released hardcopy Mar 89 X3J13
Comments: Cleanup forum? For 'future directions'?
+ SUBSEQ-OUT-OF-BOUNDS
29-MAR-88 Version 2
Status: Passed, 1988?
- SUBTYPEP-ENVIRONMENT
Version 1, 2-Jan-89
Status: missing writeup, didn't get to, withdraw
+ SUBTYPEP-TOO-VAGUE
Version 4, 7-Oct-88, Released 7 Oct 88
Status: passed, Jan 89 X3J13
+ SYMBOL-MACROLET-DECLARE
Version 2, 9-Dec-88, Released 9 Dec 88
Status: passed, Jan 89 X3J13
+ SYMBOL-MACROLET-SEMANTICS
Status: Version 5, Passed, Jan 89 X3J13
Version 6, 14-Mar-89, released 16-Mar-89
Status: Version 6 (reconsidered), passed, Mar 89 X3J13
- TAIL-RECURSION-OPTIMIZATION
Version 2, Oct 88?
Status: dropped somehow?
+ TAILP-NIL
Version 5, 9-Dec-88, Released 12-Dec-88
Synopsis: Operation of TAILP given NIL
Status: passed, Jan 89 X3J13
+ TEST-NOT-IF-NOT
Version 3, 1 Dec 88, Released 9 dec
Version 4, 18-Mar-89
Status: Need new version as amended.
* THE-AMBIGUITY
Version 2, 11-Jan-89, Released 11-Jan-89
Comments: typo, sense wrong
Status: didn't come up Mar 89 X3J13; withdraw?
+ TIME-ZONE-NON-INTEGER
Version 1, 13-Mar-89, Released 16-Mar-89
Version 2, 10-Apr-89, as amended Mar 89 X3J13 (not released, on arisia)
Status: passed, as amended, Mar 89 X3J13
* TYPE-OF-UNDERCONSTRAINED
Version 3, 12-Dec-88, Released 12 Dec 88
Comments: Accepted, with amendments
Version 5, 16-Mar-89
Comments: Moon's comments, only some responses. Fix
Status: need new version
* UNDEFINED-VARIABLES-AND-FUNCTIONS
Synopsis: What happens on an undefined function call, unbound variable ref?
Version 1, 29-Nov-88, Released 11-Jan-89
Comments: offline discussion about SLOT-UNBOUND
Status: ? didn't get to; withdraw?
+ UNREAD-CHAR-AFTER-PEEK-CHAR
Version 2, 2-Dec-88, Released 12-Dec-88
Status: passed, Jan 89 X3J13
+ VARIABLE-LIST-ASYMMETRY
Version 3, 08-Oct-88, Released 9 Dec 88
Status: passed, Jan 89 X3J13
+ WITH-OUTPUT-TO-STRING-APPEND-STYLE
Version 5, 7-JUN-88
Status: Passed, 1988
* WITH-OPEN-FILE-DOES-NOT-EXIST
Version 1, 17-Mar-89
Status: didn't get to; withdraw?
∂10-Apr-89 1303 CL-Cleanup-mailer Issue: LOAD-TRUENAME (Version 3)
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 10 Apr 89 13:02:56 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 574569; Mon 10-Apr-89 16:02:52 EDT
Date: Mon, 10 Apr 89 16:02 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: LOAD-TRUENAME (Version 3)
To: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <890410160211.8.KMP@BOBOLINK.SCRC.Symbolics.COM>
This is not just a report on what happened at the meeting.
In this version, I did the following:
- Merged my `proposed amendments.'
- Ignored Moon's version 2 by his request. It was only very slightly
different than my `proposed amendments,' which he liked better.
- Changed the description of the ...-PATHNAME* variables to say they
hold a pathname that has already been merged with the defaults by
LOAD and COMPILE-FILE.
The Proposal and Rationale are the only sections which changed since v1.
-kmp
-----
Issue: LOAD-TRUENAME
Forum: Cleanup
References: LOAD (p426), PROVIDE (p188), REQUIRE (p188),
Issue REQUIRE-PATHNAME-DEFAULTS
Category: ADDITION
Edit history: 13-Mar-89, Version 1 by Pitman
29-Mar-89, Version 2 by Moon (add -PATHNAME vars)
10-Apr-89, Version 3 by Pitman (clarify v2)
Problem Description:
It is difficult to construct sets of software modules which work
together as a unit and which port between different implementations.
REQUIRE and PROVIDE were intended to provide this level of support
but have `failed' to be portable in practice.
Typical user configurations involve a `system definition' file which
loads the modules of a `system' (collection of software modules).
Among the specific problems which arise are:
- File system types may vary. Different file syntax must be used for
each site.
- Even with the same Lisp implementation and host file system type,
the directory in which a software system resides may differ from
delivery site to delivery site.
- Multiple `copies' of the same system may reside in different
directories on the same machine.
Proposal (LOAD-TRUENAME:NEW-PATHNAME-VARIABLES):
Introduce new variables:
*LOAD-TRUENAME* [Variable]
This special variable is initially NIL, but is bound by LOAD to
hold the truename of the pathname of the file being loaded.
*COMPILE-FILE-TRUENAME* [Variable]
This special variable is initially NIL, but is bound by
COMPILE-FILE to hold the truename of the pathname of the file
being compiled.
*LOAD-PATHNAME* [Variable]
This special variable is initially NIL but is bound by LOAD
to hold a pathname which represents the filename given as the
first argument to LOAD merged against the defaults.
That is, (PATHNAME (MERGE-PATHNAMES arg1)).
*COMPILE-FILE-PATHNAME* [Variable]
This special variable is initially NIL but is bound by COMPILE-FILE
to hold a pathname which represents the filename given as the
first argument to COMPILE-FILE merged against the defaults.
That is, (PATHNAME (MERGE-PATHNAMES arg1)).
Example:
------ File SETUP ------
(IN-PACKAGE 'MY-STUFF)
(DEFMACRO COMPILE-TRUENAME () `',*COMPILE-FILE-TRUENAME*)
(DEFVAR *SOURCE-FILE* (COMPILE-TRUENAME) "Just for debugging.")
(DEFVAR *LOADED-FILE* *LOAD-TRUENAME*)
(DEFUN LOAD-MY-SYSTEM ()
(DOLIST (MODULE-NAME '("FOO" "BAR" "BAZ"))
(LOAD (MERGE-PATHNAMES MODULE-NAME *LOAD-TRUENAME*))))
------------------------
(LOAD "SETUP")
(LOAD-MY-SYSTEM)
Rationale:
This satisfies the most common instances of the frequently reported
problem in the Problem Description.
The ...-TRUENAME* variables are useful to tell the real file being
loaded.
The ...-PATHNAME* variables are useful to find information about
the original link names or logical device names mentioned in the
pathname to be opened but no longer reflected in the truename.
Note that it is not adequate to just have the -PATHNAME* variables
since TRUENAME on these pathnames might not yield the value of the
-TRUENAME* variables if the file has been deleted or protected
since the open occurred (in some implementations).
Current Practice:
Wide variation.
In some implementations, calling LOAD binds or sets
*DEFAULT-PATHNAME-DEFAULTS* so that pathnames named in a file being
LOADed will default to being `nearby.'
Some implementations provide special variables that are similar or
identical to one or both of those proposed.
Some implementations have a way to represent the pathname for the
current working directory, and make the default pathname default
to that, so that loading without specifying a default again tends to
get `nearby' files.
None of these techniques is portable, unfortunately, because there
is no agreement.
Cost to Implementors:
Very small.
Cost to Users:
None. This change is upward compatible.
Cost of Non-Adoption:
Continued difficulty for anyone trying to put a system of modules
in a form where they can be conveniently delivered using portable code.
Benefits:
The cost of non-adoption is avoided.
Aesthetics:
Negligible.
Discussion:
Touretzky raised the issue most recently on Common-Lisp. A number
of people immediately jumped on the bandwagon, indicating it was
important to them, too.
Pitman made three suggestions in response, of which the above is
the first. The others included:
2. Variables *LOAD-TRUENAMES* and *COMPILE-FILE-TRUENAMES* which hold
lists of the truenames of all files being loaded or compiled,
respectively, during the dynamic invocation of LOAD and COMPILE-FILE.
3. Variable *LOAD-OR-COMPILE-FILE-TRUENAMES* which holds a list like
((LOAD truename) (COMPILE-FILE truename) ...)
during the dynamic invocation of LOAD and COMPILE-FILE.
Touretzky responded:
``I like KMP's proposals. I like the second one best: have separate
variables for files being loaded and files being compiled, and use
them to maintain a stack so we can see the nesting of loads within
files.''
Pitman ultimately chose to present the first rather than the second
because it seemed simpler, easier to explain, and more likely to
pass at this late date.
∂10-Apr-89 1349 CL-Cleanup-mailer Issue: LOAD-TRUENAME (Version 3)
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 10 Apr 89 13:49:07 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 574621; Mon 10-Apr-89 16:48:51 EDT
Date: Mon, 10 Apr 89 16:48 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: LOAD-TRUENAME (Version 3)
To: CL-Cleanup@SAIL.Stanford.EDU
In-Reply-To: <890410160211.8.KMP@BOBOLINK.SCRC.Symbolics.COM>
Message-ID: <19890410204842.3.MOON@EUPHRATES.SCRC.Symbolics.COM>
I approve this version. I checked it against the amendment
I had proposed.
In the example section,
(LOAD (MERGE-PATHNAMES MODULE-NAME *LOAD-TRUENAME*))))
should be
(LOAD (MERGE-PATHNAMES MODULE-NAME *LOAD-PATHNAME*))))
That's the whole reason for the amendment to add *LOAD-PATHNAME*!
The discussion section ought to include someone's suggestion that all
these variables could be replaced by *LOAD-STREAM* and
*COMPILE-FILE-STREAM*, combined with the existing PATHNAME and TRUENAME
functions. It should also include someone else's suggestion that those
two variables could be replaced by *STANDARD-INPUT*. I think there was
some argument against allowing access to the stream that convinced me to
support this proposal instead, but that other suggestion ought to be
given fair representation.
∂10-Apr-89 1621 CL-Cleanup-mailer Issue: PATHNAME-CANONICAL-TYPE
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 10 Apr 89 16:21:00 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 574802; Mon 10-Apr-89 19:21:01 EDT
Date: Mon, 10 Apr 89 19:20 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: PATHNAME-CANONICAL-TYPE
To: CL-Cleanup@sail.stanford.edu
Message-ID: <19890410232048.0.MOON@EUPHRATES.SCRC.Symbolics.COM>
Larry suggests a simpler proposal than Kent's. Here is some background
on pathname canonical types in general:
There are three purposes served by pathname canonical types:
(1) Construction. There is currently no portable way to construct a
pathname that follows local file naming conventions. For example, given
a program named "foo", we'd like to construct the conventional names for
its source and compiled files. These will be "foo.l" and "foo.b" on one
system, "FOO.LSP" and "FOO.BIN" on another system, and "foo.lisp" and
"foo.ibin" on a third system.
More generally, we would like to be able to access naming conventions
for many types of files, not just Lisp source and compiled Lisp. A
simplifying assumption is that all naming conventions affect only the
type field. Thus a facility to translate canonical types into actual
types is sufficient. Another assumption is that a given file system
always uses the same actual type for a given class of file; Symbolics
pathname canonical types are more general than this, but that is not
being proposed here, as it was primarily useful only in connection with
a transition between different releases of Unix, an application too
specialized to be enshrined in Common Lisp.
We would also like users to be able to define new classes of files of
their own, with associated file-system-dependent naming conventions.
For example, if I write a portable `defsystem', I would use a unique
naming convention for the file in which it stores its configuration
database. The naming convention might not use the same string on every
file system, so it should be a canonical type.
(2) Recognition. There is currently no portable way to classify a file
from its pathname. If I write a portable editor, I would like to be
able to recognize the syntax of a program source file from its pathname
type field (Lisp, C, Ada, etc.) The same table of local file naming
conventions used in part 1 can be accessed in reverse to translate an
actual type to a canonical type. The editor can then look up the
canonical type in a table of known languages.
There is a tension here between two goals when there are subclasses of
files. Consider two systems that can cross-compile for each other.
This clearly involves two canonical types for compiled Lisp files.
Should the canonical type reflect the system for which the file was
compiled, so that the canonical type of a particular file has the same
value in both systems? Or should both systems use the same canonical
type for files compiled to be loaded locally, so that the canonical type
of a particular usage of a file has the same value in both systems?
(3) Translation. There is currently no portable way to translate a
pathname written in the file naming conventions of one file system into
a pathname written in the file naming conventions of a different file
system. A trivial use for this is cross-host pathname defaulting and
merging in a heterogeneous network, e.g. so a portable copy file command
can default the output file name intelligently. A much more important
use is in logical pathnames (logical pathnames are a universal file
system that is mapped into the locally available file system through
site-dependent translations; this is primarily useful in software
distribution), where it is necessary to translate accurately between
logical pathname file naming conventions and local file naming
conventions. The table of file naming conventions used in part 1 can be
accessed in reverse to identify the canonical type of a logical
pathname, and then accessed forwards to translate to the actual type to
be used on the local file system.
Whether we want Common Lisp to support these three features in a
portable fashion is of course a matter of policy. Omitting any or all
of the features does not make the language unusable, it just means two
things: Users writing programs not intended to be portable will build
the local conventions directly into their programs, causing problems
later if they change their minds about portability. Every user writing
a portable program that needs such capabilities has to implement them
himself, or obtain them from some supplier other than the Common Lisp
language, which will produce a small non-portable appendage to the
program that has to be redone for each port.
Critique of the proposals:
Larry's proposal addresses only the first paragraph of part 1. It
does not allow user definition of file naming conventions and does
not support recognition or translation at all.
Kent's proposal addresses part 2 and the first paragraph of part 1.
It probably extends trivially to address part 3 as well, by adding
a statement that MERGE-PATHNAMES uses canonical types to merge
the type field.
As noted in the discussion section of the proposal, I would prefer
a proposal that addressed all three parts, which would require a
way to name file system types. We could follow the standard defined
by the Internet Domain Name system.
∂11-Apr-89 0714 CL-Cleanup-mailer Issue: LOAD-TRUENAME (Version 4)
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 11 Apr 89 07:14:20 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 575061; Tue 11-Apr-89 10:12:53 EDT
Date: Tue, 11 Apr 89 10:12 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: LOAD-TRUENAME (Version 4)
To: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <890411101208.3.KMP@BOBOLINK.SCRC.Symbolics.COM>
New version to accomodate Moon's comments.
I changed the Example a bit.
I added a paragraph to the Discussion.
Everything else is the same.
I'm hoping this is a final version.
-kmp
-----
Issue: LOAD-TRUENAME
Forum: Cleanup
References: LOAD (p426), PROVIDE (p188), REQUIRE (p188),
Issue REQUIRE-PATHNAME-DEFAULTS
Category: ADDITION
Edit history: 13-Mar-89, Version 1 by Pitman
29-Mar-89, Version 2 by Moon (add -PATHNAME vars)
10-Apr-89, Version 3 by Pitman (clarify v2)
11-Apr-89, Version 4 by Pitman (merge Moon's v3 comments)
Problem Description:
It is difficult to construct sets of software modules which work
together as a unit and which port between different implementations.
REQUIRE and PROVIDE were intended to provide this level of support
but have `failed' to be portable in practice.
Typical user configurations involve a `system definition' file which
loads the modules of a `system' (collection of software modules).
Among the specific problems which arise are:
- File system types may vary. Different file syntax must be used for
each site.
- Even with the same Lisp implementation and host file system type,
the directory in which a software system resides may differ from
delivery site to delivery site.
- Multiple `copies' of the same system may reside in different
directories on the same machine.
Proposal (LOAD-TRUENAME:NEW-PATHNAME-VARIABLES):
Introduce new variables:
*LOAD-TRUENAME* [Variable]
This special variable is initially NIL, but is bound by LOAD to
hold the truename of the pathname of the file being loaded.
*COMPILE-FILE-TRUENAME* [Variable]
This special variable is initially NIL, but is bound by
COMPILE-FILE to hold the truename of the pathname of the file
being compiled.
*LOAD-PATHNAME* [Variable]
This special variable is initially NIL but is bound by LOAD
to hold a pathname which represents the filename given as the
first argument to LOAD merged against the defaults.
That is, (PATHNAME (MERGE-PATHNAMES arg1)).
*COMPILE-FILE-PATHNAME* [Variable]
This special variable is initially NIL but is bound by COMPILE-FILE
to hold a pathname which represents the filename given as the
first argument to COMPILE-FILE merged against the defaults.
That is, (PATHNAME (MERGE-PATHNAMES arg1)).
Example:
------ File SETUP ------
(IN-PACKAGE "MY-STUFF")
(DEFMACRO COMPILE-TRUENAME () `',*COMPILE-FILE-TRUENAME*)
(DEFVAR *MY-COMPILE-TRUENAME* (COMPILE-TRUENAME) "Just for debugging.")
(DEFVAR *MY-LOAD-PATHNAME* *LOAD-PATHNAME*)
(DEFUN LOAD-MY-SYSTEM ()
(DOLIST (MODULE-NAME '("FOO" "BAR" "BAZ"))
(LOAD (MERGE-PATHNAMES MODULE-NAME *MY-LOAD-PATHNAME*))))
------------------------
(LOAD "SETUP")
(LOAD-MY-SYSTEM)
Rationale:
This satisfies the most common instances of the frequently reported
problem in the Problem Description.
The ...-TRUENAME* variables are useful to tell the real file being
loaded.
The ...-PATHNAME* variables are useful to find information about
the original link names or logical device names mentioned in the
pathname to be opened but no longer reflected in the truename.
Note that it is not adequate to just have the -PATHNAME* variables
since TRUENAME on these pathnames might not yield the value of the
-TRUENAME* variables if the file has been deleted or protected
since the open occurred (in some implementations).
Current Practice:
Wide variation.
In some implementations, calling LOAD binds or sets
*DEFAULT-PATHNAME-DEFAULTS* so that pathnames named in a file being
LOADed will default to being `nearby.'
Some implementations provide special variables that are similar or
identical to one or both of those proposed.
Some implementations have a way to represent the pathname for the
current working directory, and make the default pathname default
to that, so that loading without specifying a default again tends to
get `nearby' files.
None of these techniques is portable, unfortunately, because there
is no agreement.
Cost to Implementors:
Very small.
Cost to Users:
None. This change is upward compatible.
Cost of Non-Adoption:
Continued difficulty for anyone trying to put a system of modules
in a form where they can be conveniently delivered using portable code.
Benefits:
The cost of non-adoption is avoided.
Aesthetics:
Negligible.
Discussion:
Touretzky raised the issue most recently on Common-Lisp. A number
of people immediately jumped on the bandwagon, indicating it was
important to them, too.
Pitman made three suggestions in response, of which the above is
the first. The others included:
2. Variables *LOAD-TRUENAMES* and *COMPILE-FILE-TRUENAMES* which hold
lists of the truenames of all files being loaded or compiled,
respectively, during the dynamic invocation of LOAD and COMPILE-FILE.
3. Variable *LOAD-OR-COMPILE-FILE-TRUENAMES* which holds a list like
((LOAD truename) (COMPILE-FILE truename) ...)
during the dynamic invocation of LOAD and COMPILE-FILE.
Touretzky responded:
``I like KMP's proposals. I like the second one best: have separate
variables for files being loaded and files being compiled, and use
them to maintain a stack so we can see the nesting of loads within
files.''
Pitman ultimately chose to present the first rather than the second
because it seemed simpler, easier to explain, and more likely to
pass at this late date.
Other suggestions which were considered discarded were:
a. Provide just variables *LOAD-STREAM* and *COMPILE-FILE-STREAM*.
Then PATHNAME and TRUENAME could be used to yield the
information contained in the -PATHNAME* and -TRUENAME* variables
of the proposal above.
b. Like (a), but call both variables *STANDARD-INPUT*. That is,
say that LOAD and COMPILE-FILE bind *STANDARD-INPUT* to the
stream being loaded.
There were a number of pitfalls with this approach which all center
around the way it invites the user to do other operations besides
PATHNAME and TRUENAME. Not only would some people be confused by
the difference between the characteristics of *LOAD-STREAM* for
compiled and interpreted files, but also even with interpreted
streams, the actual position of the stream pointer at the time of
execution of the forms contained in the file could vary between
implementations in a way that became a lurking portability barrier.
Since the observed user need which spawned this discussion was for
a way to tell what file was being loaded and not for a way to
manipulate the stream, it seemed best to just go with the variables
that addressed that specific need--fewer pitfalls and more perspicuous
code are likely to result.
∂11-Apr-89 2155 CL-Cleanup-mailer Re: Issue: PATHNAME-CANONICAL-TYPE
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 11 Apr 89 21:55:01 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 11 APR 89 21:54:37 PDT
Date: 11 Apr 89 21:53 PDT
From: masinter.pa@Xerox.COM
Subject: Re: Issue: PATHNAME-CANONICAL-TYPE
In-reply-to: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>'s message
of Mon, 10 Apr 89 19:20 EDT
To: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
cc: CL-Cleanup@sail.stanford.edu
Message-ID: <890411-215437-9502@Xerox>
I like your analysis. My argument is that the first paragraph of (1) is the
"most important", and is the only one that I think can be solved. While we
can make some requirements on lisp system's naming conventions, e.g., that
the naming convention that distinguishes a Lisp source and compiled Lisp
must affect only the type field, we can't require that of other
applications. Since your "assumptions" are often false ("all naming
conventions affect only the type field", "a given file system always uses
the same actual type for a given class of file"), a design which presumes
they are true are not good canditates for the standard.
Similarly, there are numerous file systems where there is no good canonical
mapping from pathname-type to actual knowledge of the kind of file, and so
the prerequesites are not satisifed for being able to do recognition and
translation based merely on pathname-type. (I'm thinking of the Macintosh,
where the actual file type is frequently encoded not in the pathname but
rather in the 'creator' and 'type' fields, and DOS, where the three
character limit means that the same pathname-type is frequently used for
different interpretations by different applications, and some Xerox
systems, where the actual file type is encoded by a 16-bit file attribute,
etc.)
I don't think it is merely a matter of policy whether Common Lisp should
support all three features; I think it is also a matter of feasibility. If
supporting the features is in fact impossible in many file systems, we
shouldn't require them to be supported. Since Lisp implementors have
control over the file types used by their compiler, we can require
canonical values for make-pathname, however.
∂12-Apr-89 1012 CL-Cleanup-mailer issue PRETTY-PRINT-INTERFACE
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 12 Apr 89 10:12:12 PDT
Received: from defun.utah.edu by cs.utah.edu (5.61/utah-2.1-cs)
id AA07535; Wed, 12 Apr 89 11:12:05 -0600
Received: by defun.utah.edu (5.61/utah-2.0-leaf)
id AA03186; Wed, 12 Apr 89 11:12:03 -0600
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8904121712.AA03186@defun.utah.edu>
Date: Wed, 12 Apr 89 11:12:02 MDT
Subject: issue PRETTY-PRINT-INTERFACE
To: cl-cleanup@sail.stanford.edu
I've finally found time to look over the hardcopy of this issue that
was distributed at the March meeting, but I'm having an extremely
difficult time parsing it. The description is spread out in too many
places (the proposal section, the list of amendments, and the attached
document), and there are some things mentioned in the discussion
section that appear to contradict what is actually in the proposal
(like whether the list form of the CONS type specifier is a real type
specifier or not). Can somebody please revise this writeup so that it
is organized more coherently? I realize this issue is long and
complicated, but improving the presentation would make it a lot more
understandable.
-Sandra
-------
∂14-Apr-89 0700 CL-Cleanup-mailer Status of CL Condition Handling
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 14 Apr 89 07:00:00 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 577300; Fri 14-Apr-89 10:00:03 EDT
Date: Fri, 14 Apr 89 09:59 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Status of CL Condition Handling
To: CL-Cleanup@SAIL.Stanford.EDU, CL-Error-Handling@SAIL.Stanford.EDU
cc: Gateley@tilde.csc.ti.com
In-Reply-To: <2817520854-15094035@Casablanca>
Message-ID: <890414095910.1.KMP@BOBOLINK.SCRC.Symbolics.COM>
Messages like the following are increasingly common these days.
Date: Thu, 13 Apr 89 23:40:54 CDT
From: John Gateley <Gateley@tilde.csc.ti.com>
Subject: CLEH
Could you send me a pointer to the latest description of CLEH? I have
the 3/12/88 version of 'Condition System Revision 18'?
I checked with David Bartley, our representative to X3J13 and he doesn't
have anything more recent.
I really don't mind fielding this sort of question and have been doing so
for a long time, but since it has been asked a lot lately, I'm sending this
one-shot message just so there will be a recent message that people can
refer to when bringing others up to date.
----- Status of Condition Handling in Common Lisp, April 1989 -----
The most current revision of the error handling document is
Common Lisp Condition System, Version 18. This document was voted
in to CL (in the same sense as CLOS and LOOP have been) and in my
mind it occupies essentially the same status in the standard as
does CLtL. That is, it has been affected by and may be further
affected by action of the Cleanup committee. The effect of its
acceptance was not to cast it in concrete and prohibit change,
but rather to establish that the default is that what it says will
end up in the standard unless someone acts to change that default.
Until the standard is finally voted in as a single unit, nothing is
a certainty.
Version 18 of the condition proposal document is available from
AI.AI.MIT.EDU in the file named "COMMON;COND18 TEXT".
A `sample implementation' is available from AI.AI.MIT.EDU in the
file named "COMMON;COND18 LISP". The sample implementation is not
binding on the proposal text. It is merely `recommended reading'
for anyone who is about to implement the proposal.
With the advent of the proposal's adoption by X3J13 last fall, the
the error handling subcommittee was effectively disbanded. I seem
to still be handling some of what would have been its business, but
I no longer formally consider the group to be an active one or myself
to be the moderator. Changes since the proposal have been and are
being handled by the Cleanup committee.
The window is closed for most Cleanup changes which are feature
additions. The effect of this is that CL-ERROR-HANDLING@SAIL.STANFORD.EDU
is a dormant list. As cleanup items are approved, no new central
error handling document is being produced to minimize administrative
overhead. The approved items will be directly absorbed by the full
standard document itself.
At this point, the only changes being seriously considered by Cleanup
are `essential functionality' that has slipped through the cracks,
or `clarifications' and `bug fixes.'
The cleanup items which are of most interest are:
CLOS-CONDITIONS - Version 4, option INTEGRATE was adopted at the
Mar-89 meeting.
ERROR-CHECKING-IN-NUMBERS-CHAPTER - A proposal for what conditions
should be signalled (and when) by the functions in the numbers
chapter. This will be discussed at the next X3J13 meeting. Other
proposals of similar kind may appear at that time as well.
CONDITION-RESTARTS - A proposal for associating conditions with
restarts. This has been a long-acknowledged weakness in the
condition system. This proposal will come up in some form at the
next X3J13 meeting, but will probably change before it does.
Some changes under consideration:
- Eliminate the proposed COPY-CONDITION function
- Eliminate SIGNAL-WITH-RESTARTS in favor of a change to
RESTART-CASE that makes it automatically create an association
when its first `argument' is a SIGNAL, WARN, ERROR, or CERROR
expression.
- Change the syntax of WITH-CONDITION-RESTARTS to get
condition-form and restarts-form as two arguments instead of
as one argument with funny syntax.
These cleanup items are generally available via anonymous FTP from
ARISIA.XEROX.COM in the directories /clcleanup/pending/ and
/clcleanup/passed/, depending on whether they are pending or passed.
Cleanup items for which there is some interest but not yet any proposal
are:
CONDITIONS-PACKAGE - Some people think the LISP package (now the
COMMON-LISP package, I guess, since a recent vote on issue
LISP-PACKAGE-NAME) is too cluttered and that we should make a new
package for some of the CONDITIONS stuff. (Many of the same people
think the same about CLOS, by the way.)
CONDITION-METACLASS - We've never specified the metaclass of
conditions so right now you can really only safely mix together
condition classes with other condition classes. People have
expressed interest in doing other kinds of mixing, which would
require knowing the metaclass of objects of class CONDITION.
If this leaves unanswered questions about any of this and you are
not an X3J13 representative, please direct them first to the X3J13
rep from your organization. If you have no rep or if your rep can't
answer your question (or if you are the rep and can't answer your own
question :-), you can direct your queries directly to me if you don't
consider them of broad interest and just want them handled privately.
∂17-Apr-89 1301 CL-Cleanup-mailer [Robert S. Boyer <boyer@CLI.COM>: Fast IO]
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 17 Apr 89 13:01:31 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 17 APR 89 12:44:48 PDT
Date: 17 Apr 89 12:44 PDT
From: masinter.pa@Xerox.COM
Subject: [Robert S. Boyer <boyer@CLI.COM>: Fast IO]
To: cl-cleanup@sail.stanford.edu
cc: wfs@CLI.COM, boyer@CLI.COM
reply-to: cl-cleanup@sail.stanford.edu, wfs@CLI.COM, boyer@CLI.COM
Message-ID: <890417-124448-22081@Xerox>
If two implementations need some declaration for 'simple' streams so that
READ-CHAR and friends can be fast, maybe this is a more generally felt
need? I thought I'd go ahead and forward to a wider forum....
----- Begin Forwarded Messages -----
Date: Mon, 17 Apr 89 14:31:51 CDT
From: Robert S. Boyer <boyer@CLI.COM>
To: masinter.pa
Cc: wfs@CLI.COM, jonl@lucid.com
Subject: Fast IO
Reply-To: boyer@cli.com
Sorry for not being informative about read-char, fast-read-char, and
:in-line.
In both Lucid and AKCL, it takes about 60 microseconds on a Sun-3/280
to do a read-char or read-byte in the usual case. That is a lot of
time! I am not really sure why it should take so long, but it does.
Something about doing necessary checking that the stream is not fancy,
bidirectional, etc., etc. (I am not making exact timing remarks here
-- just ballpark.)
Of course, in Unix on a Sun-3/280, the C programmer can get a
character in a couple of microseconds (again, ballpark). So both
Lucid and AKCL have non-CLTL extensions to make it possible to move
characters at microsecond speeds. Lucid does this by defining 6
functions that have a "fast-" prefix, e.g. fast-read-char. AKCL
(1.112) adds a new declaration (:in-line) whose semantics is something
like "I hereby assert that here is a really simple sort of stream and
I want the AKCL compiler to therefore lay down fast code for
read-char".
If these explanations don't suffice, I'm in over my head. I am
speaking here just as a user, not an implementor; but I am a user who
sees the necessity of a fast way to read characters in any Common
Lisp. I suspect that since both AKCL and Lucid have run into this
problem, other von Neumann machine Lisps will too. (In fact, my
recollection is that read-char stood a lot of room for speeding up on
Lispms, too, perhaps for the same reasons.)
I personally like the AKCL idea of somehow adding a declaration that a
stream is "simple". As it is, in our theorem-prover code we now do a
(proclaim '(declaration :in-file)), which, as I understand it, means
that :in-file declarations will be ignored by, say, the Lucid compiler
or any other compiler that doesn't know about :in-line. read-char
will go fast in AKCL, but the code will also work in Lucid. If we
were to use Lucid's fast-read-char, say, that would work for Lucid but
we would need dialect conditionals defining such a function to get
fast-read-char to work in other Lisps besides Lucid. We abhor dialect
conditionals.
I would much prefer a CLTL uniform nomenclature, any nomenclature,
fast-read-char, :in-line, or anything else.
Thanks,
Bob
P.S. If you have any serious questions about :in-line, I suspect that
Schelter (wfs@cli.com) will be happy to answer them.
----- End Forwarded Messages -----
∂19-Apr-89 0707 CL-Cleanup-mailer [Robert S. Boyer <boyer@CLI.COM>: Fast IO]
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 19 Apr 89 07:07:32 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 580833; Tue 18-Apr-89 19:20:16 EDT
Date: Tue, 18 Apr 89 19:20 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: [Robert S. Boyer <boyer@CLI.COM>: Fast IO]
To: cl-cleanup@sail.stanford.edu, wfs@CLI.COM, boyer@CLI.COM
In-Reply-To: <890417-124448-22081@Xerox>
Message-ID: <19890418232014.4.MOON@EUPHRATES.SCRC.Symbolics.COM>
Symbolics Genera is even slower at read-char. But I don't think a
declaration is the answer. I believe that if we wanted to make
read-char fast on streams where it can be fast (simple buffered
streams), a simple-stream declaration would not add any significant
additional speed. It might save about 2 microseconds for an indirect
call. This is assuming that compatibility with past implementations
of streams was not an issue (and I don't think it's reasonable in
designing a new language to assume that such would be an issue).
I know that Symbolics Genera read-char is slow because we haven't
made any effort to make it fast, not because non-simple streams make
it impossible to make it fast. I can't speak for Lucid but I wouldn't
be surprised if the story is the same for them. So I'd oppose adding
anything to the language in this area. Instead, customers should signal
to implementors their discontent with the current quality of implementation
of read-char. Implementors can then raise the priority of that and
possibly shift resources from other things.
∂19-Apr-89 1519 CL-Cleanup-mailer no :in-file
Received: from CLI.COM by SAIL.Stanford.EDU with TCP; 19 Apr 89 15:18:54 PDT
Received: by CLI.COM (4.0/1); Wed, 19 Apr 89 17:15:32 CDT
Date: Wed, 19 Apr 89 17:15:32 CDT
From: Robert S. Boyer <boyer@CLI.COM>
Message-Id: <8904192215.AA03885@CLI.COM>
To: Moon@STONY-BROOK.SCRC.Symbolics.COM
Cc: cl-cleanup@sail.stanford.edu, wfs@CLI.COM
Subject: no :in-file
Reply-To: boyer@cli.com
I now concur with Moon's view that stream declarations are unnecessary
in principle, especially in view of the fact that Bill Schelter has
now implemented very fast (couple of microsecond)
read/write//char-byte in AKCL without the necessity of declarations or
specially named functions.
∂19-Apr-89 1528 CL-Cleanup-mailer [Robert S. Boyer <boyer@CLI.COM>: Fast IO]
Received: from CLI.COM by SAIL.Stanford.EDU with TCP; 19 Apr 89 15:28:36 PDT
Received: by CLI.COM (4.0/1); Wed, 19 Apr 89 17:24:42 CDT
Date: Wed, 19 Apr 89 17:24:42 CDT
From: Bill Schelter <wfs@CLI.COM>
Message-Id: <8904192224.AA03946@CLI.COM>
To: Moon@STONY-BROOK.SCRC.Symbolics.COM
Cc: cl-cleanup@sail.stanford.edu, boyer@CLI.COM
In-Reply-To: David A. Moon's message of Tue, 18 Apr 89 19:20 EDT <19890418232014.4.MOON@EUPHRATES.SCRC.Symbolics.COM>
Subject: [Robert S. Boyer <boyer@CLI.COM>: Fast IO]
Reply-To: wfs@cli.com
I had originally felt it might be a good idea to have a specialized
type of stream for faster io in common lisp, but now am in accord with
Moon that this is simply not necessary.
Just before receiving his message I had finished reworking the
write-byte/write-char and read-byte/read-char WITHOUT declarations, so
they are now in the 2 to 3 microsecond range respectively, in
AKCL(version 1.116) on a sun3/280. The difference between this and
what I could do with a specialized stream was practically not possible
to time, when reading or writing a million characters. Of course
streams other than file streams and interprocess streams are still
substantially slower, but that is probably reasonable (for the
moment..).
Bill Schelter
∂19-Apr-89 1557 CL-Cleanup-mailer no :in-file
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 19 Apr 89 15:54:32 PDT
Received: from blacksox ([192.9.201.39]) by heavens-gate.lucid.com id AA11844g; Wed, 19 Apr 89 15:54:11 PDT
Received: by blacksox id AA01834g; Wed, 19 Apr 89 15:53:40 PDT
Date: Wed, 19 Apr 89 15:53:40 PDT
From: Eric Benson <eb@lucid.com>
Message-Id: <8904192253.AA01834@blacksox>
To: boyer@cli.com
Cc: Moon@STONY-BROOK.SCRC.Symbolics.COM, cl-cleanup@sail.stanford.edu,
wfs@CLI.COM
In-Reply-To: Robert S. Boyer's message of Wed, 19 Apr 89 17:15:32 CDT <8904192215.AA03885@CLI.COM>
Subject: no :in-file
However, in order to be competitive with C in speed it would be useful
to be able to do the following:
For binary streams, declare the element-type of the stream, e.g. allow
the STREAM type specifier to take an optional element-type like ARRAY
and COMPLEX.
For binary streams, functions to read and write arrays in a single
chunk. Lucid supplies READ-ARRAY and WRITE-ARRAY as extensions.
For character input, a destructive version of READ-LINE.
∂19-Apr-89 1621 CL-Cleanup-mailer no :in-file
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 19 Apr 89 16:21:42 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 581565; Wed 19-Apr-89 19:21:33 EDT
Date: Wed, 19 Apr 89 19:21 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: no :in-file
To: Eric Benson <eb@lucid.com>
cc: boyer@cli.com, cl-cleanup@sail.stanford.edu, wfs@CLI.COM
In-Reply-To: <8904192253.AA01834@blacksox>
Message-ID: <19890419232148.9.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Wed, 19 Apr 89 15:53:40 PDT
From: Eric Benson <eb@lucid.com>
However, in order to be competitive with C in speed it would be useful
to be able to do the following:
For binary streams, declare the element-type of the stream, e.g. allow
the STREAM type specifier to take an optional element-type like ARRAY
and COMPLEX.
I see no harm in this, if someone wants to propose it. I'm not sure
whether Symbolics would use it, but I think it's a reasonable thing
for imaginable implementations to want.
For binary streams, functions to read and write arrays in a single
chunk. Lucid supplies READ-ARRAY and WRITE-ARRAY as extensions.
For character input, a destructive version of READ-LINE.
Symbolics Genera has the equivalent of all of these under different
names. The read-array and write-array (shouldn't they be called
read-vector and write-vector?) are generic and work for character
streams as well, given a string as the vector. Someone should write
a proposal for these features. It might or might not be too late
to add this to X3J13 Common Lisp, but at least everybody could use
compatible names for their extensions.
∂20-Apr-89 1454 CL-Cleanup-mailer Issue: THE-VALUES [was: intent of (THE <type> <expression>)]
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 20 Apr 89 14:54:19 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 582196; Thu 20-Apr-89 17:54:13 EDT
Date: Thu, 20 Apr 89 17:53 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: THE-VALUES [was: intent of (THE <type> <expression>)]
To: gls@Think.COM
cc: KMP@STONY-BROOK.SCRC.Symbolics.COM, CL-Cleanup@SAIL.Stanford.EDU
In-Reply-To: <8904202059.AA00383@joplin.think.com>
Message-ID: <890420175328.4.KMP@BOBOLINK.SCRC.Symbolics.COM>
[Outside world removed.]
Date: Thu, 20 Apr 89 16:59:15 EDT
From: Guy Steele <gls@Think.COM>
...
PROPOSAL:
What it boils down to, is that THE should check only as many types
as requested (and pass back only as many).
No, this is not cool. THE is supposed to act purely as a declaration,
but you are changing it to require it to pass on only as many values
as the type specifer indicates. This could change the semantics of
a suitably devious program.
Better to say that it checks as many types as requsted, but passes on
exactly the values it receives.
--Guy
Even though I agree with your position, I think it's worth our writing up
a clarification issue to make sure we're all agreed and that it's 100% clear
in the ANSI spec.
∂20-Apr-89 2003 CL-Cleanup-mailer Issue: ERROR-TERMINOLOGY (final amended version ??? Version 9)
Received: from moon.src.honeywell.com (ALTURA.HONEYWELL.COM) by SAIL.Stanford.EDU with TCP; 20 Apr 89 20:03:37 PDT
Return-Path: <alarson@src.honeywell.com>
Received: from pavo.SRC.Honeywell.COM by moon.src.honeywell.com (5.59/smail2.6.3/06-17-88);
Thu, 20 Apr 89 22:04:03 CDT id AA13750 for cl-cleanup@sail.stanford.edu
Posted-Date: Thu, 20 Apr 89 22:02:30 CDT
Received: by pavo.src.honeywell.com (3.2/SMI-3.2)
id AA08661; Thu, 20 Apr 89 22:02:30 CDT
Date: Thu, 20 Apr 89 22:02:30 CDT
From: alarson@src.honeywell.com (Aaron Larson)
Message-Id: <8904210302.AA08661@pavo.src.honeywell.com>
To: chapman%aitg.DEC@decwrl.dec.com
Cc: cl-cleanup@sail.stanford.edu
In-Reply-To: chapman%aitg.DEC@decwrl.dec.com's message of 18 Apr 89 13:19 <8904181723.AA03079@decwrl.dec.com>
Subject: Issue: ERROR-TERMINOLOGY (final amended version ??? Version 9)
>IMPLEMENTATIONS MAY BE EXTENDED An implementation is free to treat the
> situation in ANY ONE of the following ways: (1)
> When the situation occurs, an error should be
> signalled at least in safe code, OR (2) When the
> situation occurs, the "consequences are undefined",
> OR (3) When the situation occurs, the consequences are
Item (1) should either be:
When the situation occurs, an error "should be signalled",
Or simply deleted entirely since it is really a subset of (2)/(3)
>WARNING IS ISSUED A warning is issued, as described in WARN, in
> both safe and unsafe code when the situation
> is detected. Conforming code may rely on the
> fact that a warning will be issued in both
> safe and unsafe code when the situation is
> detected. Every implementation is required to
> detect this situation in both safe and unsafe
> code when the situation is detected. The
> presence of a warning will in no way alter the
> value returned by the form which caused the
> situation to occur. For example, "a warning is
> issued if a declaration specifier is not one
> of those defined in Chapter 9 of CLtL and has
> not been declared in a DECLARATION
> declaration."
"Every implementation is required to detect this situation in both safe and
unsafe code." (i.e. delete the "when the situation is detected").
Also; "The presence of a warning will in no way alter the value
returned..." is a little strong. I think some weasel words like "in the
absence of handlers for contitions of type warning, the presence of a
warning will ...". Unless of course we intend to disallow users from
setting up handlers for warnings that throw out, which would of course
change the value returned since there wouldn't be any.
∂24-Apr-89 1249 CL-Cleanup-mailer Issue COMPLEX-RATIONAL-RESULT, version 2
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 24 Apr 89 12:49:27 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 583636; Mon 24-Apr-89 15:48:28 EDT
Date: Mon, 24 Apr 89 15:48 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue COMPLEX-RATIONAL-RESULT, version 2
To: gls@THINK.COM, Masinter.pa@XEROX.COM
cc: cl-cleanup@sail.stanford.edu
In-Reply-To: <8904090537.AA00468@brigit.think.com>
Message-ID: <19890424194840.4.MOON@EUPHRATES.SCRC.Symbolics.COM>
Line-fold: No
The opinion at Symbolics is that your version 2 is good. Let's
vote it in to replace the version 1 that X3J13 already voted in.
Should we take time in June to do this, or do it by letter?
Some TeX markup snuck into the proposal section, please remove it
before releasing.
The current practice section is out of date, since there are four
examples now. I'd change it to:
Symbolics Genera 7.4 returns a (complex single-float) for the first
example, returns 1 for the second example, and returns the specified
answers for the third and fourth examples. Other implementations were
not surveyed.
Guy if you'd like to survey some other implementations that could be
helpful.
∂28-Apr-89 0944 CL-Cleanup-mailer Issue COMPLEX-RATIONAL-RESULT, version 3
Received: from Think.COM (Gateway.Think.COM) by SAIL.Stanford.EDU with TCP; 28 Apr 89 09:44:06 PDT
Received: from fafnir.think.com by Think.COM; Fri, 28 Apr 89 12:44:13 EDT
Return-Path: <gls@Think.COM>
Received: from verdi.think.com by fafnir.think.com; Fri, 28 Apr 89 12:43:29 EDT
Received: from joplin.think.com by verdi.think.com; Fri, 28 Apr 89 12:43:26 EDT
From: Guy Steele <gls@Think.COM>
Received: by joplin.think.com; Fri, 28 Apr 89 12:43:24 EDT
Date: Fri, 28 Apr 89 12:43:24 EDT
Message-Id: <8904281643.AA05966@joplin.think.com>
To: cl-cleanup@sail.stanford.edu
Cc: gls@Think.COM
Subject: Issue COMPLEX-RATIONAL-RESULT, version 3
Version 3 fixes typos and surveys a few implementations.
Prologue to version 2 follows.
This was a good thing for Moon to bring up, but I think a couple
of desirable details were left uncovered. Here is a new version
to consider in June.
Detail 1 is that a mathematically rational or complex rational
value might result from arguments that are a mixture of rational
and complex rational; or a complex rational value might result
from arguments that are rational only.
Detail 2 is that the version 1 proposal mentions (complex float)
where I believe the more specific (complex single-float) is appropriate.
Detail 3 is that in some cases the option of an ordinary float
result is desirable or required rather than a (complex single-float);
consider the ABS function, for example.
Detail 4 is that if the true mathematical result is not rational
or complex rational, I think we want to specify that the returned
value is single-float or (complex single-float).
----------------------------------------------------------------
Issue: COMPLEX-RATIONAL-RESULT
References: CLtL p.203
Category: CLARIFICATION
Edit history: Version 1, 20-Mar-89, by Moon
Version 2, 08-Apr-89, by Steele
Version 2, 28-Apr-89, by Steele
Problem description:
Referring to irrational and transcendental functions, CLtL says:
When the arguments to a function in this section are all rational and
the true mathematical result is also (mathematically) rational, then
unless otherwise noted an implementation is free to return either an
accurate result of type rational or a single-precision floating-point
approximation. If the arguments are all rational but the result cannot
be expressed as a rational number, then a single-precision
floating-point approximation is always returned.
Referring to EXPT, CLtL says:
If the base-number is of type RATIONAL and the power-number is an
INTEGER, the calculation will be exact and the result will be of
type RATIONAL; otherwise a floating-point approximation may result.
What about arguments of type (complex rational)?
Proposal (COMPLEX-RATIONAL-RESULT:EXTEND):
Extend the paragraph quoted above as follows to cover the components
of complex numbers. If the arguments to a function are all of type
(OR RATIONAL (COMPLEX RATIONAL)) and the true mathematical result is
(mathematically) a complex number with rational real and imaginary
parts, then unless otherwise noted an implementation is free to return
either an accurate result of type (OR RATIONAL (COMPLEX RATIONAL)) or
a single-precision floating-point approximation of type SINGLE-FLOAT
(permissible only if the imaginary part of the true mathematical
result is zero) or (COMPLEX SINGLE-FLOAT). If the arguments are
all of type (OR RATIONAL (COMPLEX RATIONAL)) but the result cannot be
expressed as a rational or complex rational number, then the returned
value will be of type SINGLE-FLOAT (permissible only if the imaginary
part of the true mathematical result is zero) or (COMPLEX SINGLE-FLOAT).
For EXPT of a (COMPLEX RATIONAL) to an integer power, the
calculation must be exact and the result will be of type
(OR RATIONAL (COMPLEX RATIONAL)).
Examples:
[a] (log #c(-16 16) #c(2 2)) => 3 or approximately #c(3.0 0.0)
or approximately 3.0 (unlikely)
[b] (abs #c(3/5 4/5)) => 1 or approximately 1.0
[c] (expt #c(2 2) 3) => #c(-16 16)
[d] (expt #c(2 2) 4) => -64
Rationale:
This seems most consistent with the treatment of real numbers.
Current practice:
[a] [b] [c] [d]
Symbolics Genera 7.4 #c(3.00... 1.40...e-7) 1 #c(-16 16) -64
Sun Common Lisp 3.0.1 #c(3.0 2.61...e-16) 1.0 #c(-16 16) -64
KCL of 9/16/86 on VAX #c(3.0s0 -1.40...s-7) 1.0s0 #c(-16 16) -64
Allegro CL (Mac II) #c(3.0 2.05...e-16) 1.0 #c(-16 16) -64
Cost to Implementors:
Only EXPT would have to change, since the type of the other results
is at the discretion of the implementation.
Cost to Users:
Probably none, but it is hard to predict.
Cost of non-adoption:
Slightly less self-consistent language.
Performance impact:
None of any significance.
Benefits/Esthetics:
More self-consistent language.
Discussion:
None.
∂28-Apr-89 1426 CL-Cleanup-mailer ISSUE: GCD-LCM-ZERO-ARGS
Received: from hub.ucsb.edu (ucsbcsl.ucsb.edu) by SAIL.Stanford.EDU with TCP; 28 Apr 89 14:26:38 PDT
Received: from csilvax.ucsb.edu
by hub.ucsb.edu (5.59/UCSB-v2)
id AA22234; Fri, 28 Apr 89 14:27:18 PDT
Message-Id: <8904282127.AA22234@hub.ucsb.edu>
Received: from by csilvax.ucsb.CSNET (5.51) id AA14455; Fri, 28 Apr 89 14:25:34 PDT
Date: Fri, 28 Apr 89 14:25:34 PDT
From: Skona Brittain <skona%csilvax@hub.ucsb.edu>
Posted-Date: Fri, 28 Apr 89 14:25:34 PDT
To: CL-cleanup@SAIL.Stanford.edu
Subject: ISSUE: GCD-LCM-ZERO-ARGS
Cc: skona%csilvax@hub.ucsb.edu
Issue: GCD-LCM-ZERO-ARGS
References: CLtl pg.202 and Document 86-003 pg.3
Category: CHANGE
Edit history: Revision 1 by Skona Brittain 03/22/87
Revision 2 by Skona Brittain 01/06/89
Revision 3 by Skona Brittain 04/28/89 (removed references to
cases of no args to lcm)
Problem Description:
These functions are not well-defined for sets of arguments
that include the number zero.
Proposal (GCD-LCM-ZERO-ARGS:NOT-ALLOWED):
The arguments to lcm and gcd must be positive integers.
Test Case:
(lcm 1 0) would be an error instead of having the value 0.
Rationale:
Having the least common multiple of a set of numbers be less than
the least common multiple of a proper subset of that set
violates monotonicity. For example, monotonicity is violated by
(lcm 1 0) < (lcm 1) and (lcm 0) < (lcm).
Increasing the restrictions on the candidates for the lcm should
only be able to increase the value of the least qualifying one.
What the first example is saying is that the the least multiple
of 1 is 1 but the least number that is a multiple of both 1 and 0
is 0. This is patently ridiculous. Any reasoning that says that
0 is the lcm of 1 & 0 would also say that 0 is the lcm of 1 alone,
since 0 would be considered a multiple of 1 and is less than 1.
Furthermore, it would say that 0 is the result of the lcm operation
on any set of arguments at all. Although this would be mathematically
consistent, it would not make lcm a very useful operator.
The root of the problem is that it is unnatural to apply lcm or
gcd to anything but natural numbers. Negative numbers are not
having much of an effect because they are just being treated as
if they were their absolute values, i.e. the negativity of negative
arguments is ignored, but zero really screws things up. If it is
desired that zero be an allowed argument, it should also just be ignored,
(i.e passed over, the way nil in an association list is passed over)
Current Practice:
I know of no implementations that currently implement this change.
Cost to Users:
Very slight.
Cost to Implementors:
Very slight. Should lead to a reduction in code, since most algorithms
for computing gcd and lcm are for positive integers anyway.
Benefits:
see Esthetics.
Esthetics:
Mathematical correctness is much more aesthetic than its alternatives.
Discussion:
∂28-Apr-89 1606 CL-Cleanup-mailer Issue: MULTIPLICATION-ZERO-ARGS
Received: from Think.COM (Gateway.Think.COM) by SAIL.Stanford.EDU with TCP; 28 Apr 89 16:06:30 PDT
Received: from fafnir.think.com by Think.COM; Fri, 28 Apr 89 18:17:10 EDT
Return-Path: <gls@Think.COM>
Received: from verdi.think.com by fafnir.think.com; Fri, 28 Apr 89 18:16:27 EDT
Received: from joplin.think.com by verdi.think.com; Fri, 28 Apr 89 18:16:22 EDT
From: Guy Steele <gls@Think.COM>
Received: by joplin.think.com; Fri, 28 Apr 89 18:16:19 EDT
Date: Fri, 28 Apr 89 18:16:19 EDT
Message-Id: <8904282216.AA05993@joplin.think.com>
To: cl-cleanup@sail.stanford.edu
Cc: gls@Think.COM
Subject: Issue: MULTIPLICATION-ZERO-ARGS
Issue: MULTIPLICATION-ZERO-ARGS
References: CLtl p. 199
Category: CHANGE
Edit history: Version 1 by Guy Steele 04/28/89
Problem Description:
This function is not well-defined for sets of arguments
that include the number zero.
Proposal (MULTIPLICATION-ZERO-ARGS:NOT-ALLOWED):
Integer arguments to * must be non-zero.
Test Case:
(* 1 0) would be an error instead of having the value 0.
Rationale:
Having the product of a set of integers be less than
the product of a proper subset of that set
violates monotonicity. For example, monotonicity is violated by
(* 6 0) < (* 6) and (* 0) < (*).
The multiset of prime factors of a product is the union of the
multisets of prime factors of the numbers being multiplied.
Increasing the multiset of prime factors that contribute to the
result should only be able to increase the value of result.
What the first example is saying is that the multiset of factors
of 6 has two elements {2, 3} but the product of both 6 and 0
does not. This is patently ridiculous. Any reasoning that says that
0 is the product of 6 & 0 would also say that 0 is the product of 6 alone,
since 0 has all the prime factors that 6 does and is the smallest such number.
Furthermore, it would say that 0 is the result of the multiplication operation
on any set of arguments at all. Although this would be mathematically
consistent, it would not make multiplication a very useful operator.
The root of the problem is that it is unnatural to apply multiplication to
anything but natural numbers. Multiplication over the positive integers
forms a monoid, and over the rational numbers forms a group. Negative
numbers do not have much of an effect because they can be treated as if
they were their absolute values, with signs handled separately, but zero
really screws things up. If it is desired that zero be an allowed
argument, it should also just be ignored, (i.e passed over, the way nil in
an association list is passed over)
Current Practice:
I know of no implementations that currently implement this change.
Cost to Users:
Very slight.
Cost to Implementors:
Very slight. Should lead to a reduction in code, since most algorithms
for computing products are for positive integers anyway. (Consider what
you learned in second grade.)
Benefits:
see Esthetics.
Esthetics:
Mathematical correctness is much more aesthetic than its alternatives.
Discussion:
This is not a satire. Skona's arguments about LCM are correct, and my
arguments about multiplication are of exactly the same form. Zero really
does screw up multiplication. If it were not for addition, the value of
zero to addition, and the relationship of addition to multiplication
(especially through the distributive law), we would not put up with zero.
If you formulate multiplication in terms of unions of multisets of prime
factors (a natural and convenient representation for integers if you don't
have to do addition), then there isn't even any good representation for
zero.
But addition and zero ARE important, so we agree to extend the range of
multiplication to include zero, even though it has weird properties like
destroying the invertibility of multiplication (suddenly (/ (* A B) B)
is not always equal to A).
The same holds for GCD and LCM. Yes, their behaviors for arguments that
are zero is weird and makes no sense. But we adopt these definitions
anyway because they preserve useful identities. For example, we have the
identity
(* x (gcd y z)) = (gcd (* x y) (* x z))
If x is zero, then we had better have (gcd 0 0) = 0.
If y is zero, then we have
(* x (gcd 0 z)) = (gcd 0 (* x z))
and letting (gcd 0 a) = a is the simplest way of preserving this.
Then consider
(* u v) = (* (gcd u v) (lcm u v))
Let u be zero. Then to preserve this identity at least one of
(gcd u v) and (lcm u v) must be zero. But (gcd 0 v) = v, so if
v is not zero then (lcm 0 v) had better be zero.
See Knuth, volume 2, section 4.5.2. There you will see that he finds it
convenient to use the prime-factor representation of integers to explain
gcd and lcm (and in fact during that part of the discussion he conveniently
ignores the fact that you cannot encode zero in that representation--and
for his expository purposes it doesn't matter).
So that is why gcd and lcm behave in such strange ways: they preserve
important identities in the boundary cases. A cardinal rule of
mathematics is that consistency is more important than making sense.
(In fact, consistency is the *definition* of making sense.)
So I argue that, whatever we do, we should treat GCD/LCM and multiplication
on integers in exactly the same way. Either all accept arguments that
are zero, or none do.
∂03-May-89 1653 CL-Cleanup-mailer [chapman%aitg.DEC@decwrl.dec.com: question @ SUBTYPEP-TOO-VAGUE]
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 3 May 89 16:53:46 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 03 MAY 89 16:51:25 PDT
Date: 3 May 89 16:51 PDT
From: masinter.pa@Xerox.COM
Subject: [chapman%aitg.DEC@decwrl.dec.com: question @ SUBTYPEP-TOO-VAGUE]
To: cl-cleanup@sail.stanford.edu
cc: masinter.pa@Xerox.COM
Message-ID: <890503-165125-11110@Xerox>
My record says that we passed version 4 at the January meeting, Guy
produced version 5 in March, but that we didn't discuss version 5, postpone
version 5, or otherwise deal with version 5 at the March meeting. I think
this one fell between the cracks... right?
----- Begin Forwarded Messages -----
From: chapman%aitg.DEC@decwrl.dec.com
Date: 1 May 89 13:08
To: @masinter@decwrl.dec.com
Subject: question @ SUBTYPEP-TOO-VAGUE
LM,
The last version I got of SUBTYPEP-TOO-VAGUE reads like it is
Version 5, but doesn't have Version 5 in the header. That's no
big deal, but since it has some big changes from Version 4, I
wondered if what I got was just a review copy or a final draft?
The reason you're getting this question (vs. KMP) is that your
name appeared twice and last in the revision list.
----- End Forwarded Messages -----
∂04-May-89 0922 CL-Cleanup-mailer Issue: SETF-MULTIPLE-STORE-VARIABLE
Received: from arisia.Xerox.COM by SAIL.Stanford.EDU with TCP; 4 May 89 09:22:39 PDT
Received: from layla.parc.Xerox.COM by arisia.Xerox.COM with SMTP
(5.61+/IDA-1.2.8/gandalf) id AA01288; Thu, 4 May 89 09:21:02 -0700
Reply-To: <rao@arisia.Xerox.COM>
Received: by layla. (4.0/SMI-4.0)
id AA05410; Thu, 4 May 89 09:21:58 PDT
Date: Thu, 4 May 89 09:21:58 PDT
From: Ramana Rao <rao@arisia.Xerox.COM>
Message-Id: <8905041621.AA05410@layla.>
To: cl-cleanup@sail.stanford.edu
Cc: Rao@arisia.Xerox.COM, pavel.pa@Xerox.COM, gregor@arisia.Xerox.COM,
masinter.pa@arisia.Xerox.COM
Subject: Issue: SETF-MULTIPLE-STORE-VARIABLE
This message is to encourage the cleanup committee to get to and accept this
proposal and to bring up a related issue having to do with setf generic
functions in CLOS.
The case covered by the proposal is real (or at least exactly what I want to).
I have a rectangle object that has accessors for retrieving the corner points
and the extent that return two multiple values. A motivation for doing it this
way versus with structured objects is to please users that are particularly
concerned about consing new structures. So both types of methods are provided.
(I hacked a version of setf that allows setf of these accessors.)
Example:
(defmethod rectangle-min-point ((rect rectangle))
...
(make-point min-x min-y))
(defmethod rectangle-min-point* ((rect rectangle))
...
(values min-x min-y))
(defmethod (setf* rectangle-min-point*) (min-x min-y (rect rectangle))
---
)
The related issue has to do with CLOS. How does the setf generic function know
how many store values to expect? This may be a problem with having recombined
the store varables into a single argument list.
Example:
Alternatives Solutions in order of preferrence:
1) Change syntax of methods on setf generic function.
(defmethod (setf rectangle-min-point*) (min-x min-y) ((rect rectangle))
---
)
2) Extend defgeneric to allow indicating the number of store variables expected
by the setf generic function.
3) Require user to generate setf expander using some provided macro.
(def-generic-setf rectangle-min-point* 2)
Or the following allows catching some errors at setf expansion.
(def-generic-setf rectangle-min-point* (rect) (min-x min-y))
(defmethod (setf rectangle-min-point*) (min-x min-y (rect rectangle))
---
)
∂04-May-89 1244 CL-Cleanup-mailer [chapman%aitg.DEC@decwrl.dec.com: question @ SUBTYPEP-TOO-VAGUE]
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 4 May 89 12:44:36 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 589809; 4 May 89 13:49:40 EDT
Date: Thu, 4 May 89 13:49 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: [chapman%aitg.DEC@decwrl.dec.com: question @ SUBTYPEP-TOO-VAGUE]
To: masinter.pa@Xerox.COM
cc: cl-cleanup@sail.stanford.edu
In-Reply-To: <890503-165125-11110@Xerox>
Message-ID: <19890504174937.5.MOON@EUPHRATES.SCRC.Symbolics.COM>
Line-fold: No
Date: 3 May 89 16:51 PDT
From: masinter.pa@Xerox.COM
My record says that we passed version 4 at the January meeting, Guy
produced version 5 in March, but that we didn't discuss version 5, postpone
version 5, or otherwise deal with version 5 at the March meeting. I think
this one fell between the cracks... right?
My records are consistent with that. I never studied this issue really
carefully but version 5 was okay with me, more or less. It's still a bit
bogus because an implementation could define all type specifiers as
expansions into SATISFIES, in which case SUBTYPEP could return NIL NIL
always. I suspect the proposal was intended to rule that out, but the
actual words that it says fail to rule that out.
From: chapman%aitg.DEC@decwrl.dec.com
The last version I got of SUBTYPEP-TOO-VAGUE reads like it is
Version 5, but doesn't have Version 5 in the header. That's no
big deal, but since it has some big changes from Version 4, I
wondered if what I got was just a review copy or a final draft?
The reason you're getting this question (vs. KMP) is that your
name appeared twice and last in the revision list.
Here is a better version of version 5 that I found in our archives:
Date: Wed, 15 Mar 89 17:44:14 EST
From: Guy Steele <gls@Think.COM>
Message-Id: <8903152244.AA03741@verdi.think.com>
To: cl-cleanup@sail.stanford.edu
Subject: [gls: Issue SUBTYPEP-TOO-VAGUE, version 5]
[I forgot to update the edit history. Here is corrected copy.]
Date: Wed, 15 Mar 89 17:41:16 EST
From: Guy Steele <gls>
To: cl-cleanup@sail.stanford.edu
Subject: Issue SUBTYPEP-TOO-VAGUE, version 5
Cc: gls
This is a proposed amendment to version 4 passed in January 1989 at Kauai.
Issue: SUBTYPEP-TOO-VAGUE
References: CLtL p. 72-73
Category: CLARIFICATION
Edit History: Version 1, 11 Jul 1988 (Sandra Loosemore)
Version 2, 19 Jul 1988 (Sandra Loosemore)
Version 3, 6-Oct-88 (Masinter)
Version 4, 7-Oct-88 (Masinter, per Moon's comments)
Version 5, 15-Mar-89 Steele
Problem Description:
[From version 4]
The description of SUBTYPEP allows it to return a second value of NIL
when the relationship between the two types cannot be determined. In
some cases this is a reasonable thing to do because it is impossible
to tell (if the SATISFIES type specifier is involved), and in other
cases the relationships between types are not well-defined (for
example, the VALUES type specifier or the list form of the FUNCTION
type specifier).
Some implementations, however, have apparently interpreted this to
mean that it is permissible for SUBTYPEP to "give up" and return a
second value of NIL in some cases where it actually would be possible
to determine the relationship. This makes it difficult to depend on
subtype relationships in portable code.
[Addition for version 5]
There are two problems with version 4. First is that of the first three
bulleted points in the version 4 proposal:
* Clarify that SUBTYPEP will return a second value of NIL
only when either of the type specifiers involves the SATISFIES, NOT,
AND, OR, MEMBER. SUBTYPEP will not return a second
value of NIL when both arguments involve only the words in Table 4-1, or
names of DEFSTRUCT- or DEFCLASS-defined types, or user-defined deftypes
that expand into only those words and/or names.
* SUBTYPEP should signal an error when handed (for either argument)
a type specifier that involves VALUES or the list form of the FUNCTION
type.
* SUBTYPEP must always return values T T in the case where the two
type specifiers (or their expansions) are EQUAL.
any two have significant overlap, and indeed all three can overlap;
version 4 contained no indication of how this conflict should be resolved.
Second is that version 4 calls for SUBTYPEP to signal an error (at least at
high safety)even when the arguments are valid type specifiers, but this can
make it harder to use SUBTYPEP. These are cases that returning NIL NIL
was supposed to cover.
This version replaces the three bulleted points above with a single point
and some observations about its consequences. This version eliminates
the requirement to signal an error.
Proposal: SUBTYPEP-TOO-VAGUE:CLARIFY-MORE
A type specifier "involves" a word like SATISFIES, MEMBER, NOT, etc.
if it either contains it directly or as the result of expansion of a
DEFTYPE defined type specifier.
* Clarify that SUBTYPEP is permitted to return NIL NIL only when
at least one argument involves SATISFIES, AND, OR, NOT, MEMBER,
VALUES, or the list form of FUNCTION.
Note that one consequence of this is that if neither argument
involves any of these type specifiers, then SUBTYPEP is obliged
to determine the relationship accurately. In particular, SUBTYPEP
must return T T if the arguments are EQUAL and do not involve
any of the above-stated type specifiers.
* Clarify that the relationships between types reflected by SUBTYPEP
are those specific to the particular implementation. For example, if
an implementation supports only a single type of floating-point numbers,
in that implementation (SUBTYPEP 'FLOAT 'LONG-FLOAT) would return T T
(since the two types would be identical).
Rationale:
Specifying the behavior of SUBTYPEP makes it more useful. Otherwise,
programs cannot rely on any more than NIL NIL as return values.
It is generally conceded that it is impossible to determine the
relationships between types defined with the SATISFIES specifier.
MEMBER, AND, OR, and NOT are messy to deal with.
Current Practice:
The implementation of SUBTYPEP in (the original) HPCL does not try to
expand type specifiers defined with DEFTYPE and does not recognize
EQUAL type specifiers as being equivalent. Most other implementations
appear to be substantially in conformance with the proposal.
Cost to implementors:
Some implementations will have to rewrite and/or extend parts of SUBTYPEP.
Cost to users:
Its hard to imagine a portable program that depends heavily
on SUBTYPEP. This proposal does not require any implementation
to "handle" fewer cases of SUBTYPEP.
Benefits:
An area of confusion in the language is cleared up. Usages of SUBTYPEP
will be more portable.
Discussion:
The handling of FLOAT and SINGLE-FLOAT appeared to be the
consensus from a discussion on the common-lisp mailing list some
time ago.
It would not be too onerous to require implementations to handle
the cases where one but not the other type specifier involves
OR, AND, NOT or MEMBER, but the specification becomes
cumbersome.
A related issue is clarifying what kinds of type specifiers must be
recognized by functions such as MAKE-SEQUENCE and COERCE. For example,
HPCL complains that (SIMPLE-ARRAY (UNSIGNED-BYTE *) (*)) is not a valid
sequence type when passed to MAKE-SEQUENCE, although SUBTYPEP does
recognize it to be a subtype of SEQUENCE. Should this proposal be
extended to deal with these issues, or is another proposal in order?
The rules for comparing the various type specifiers (such as ARRAY)
need to be spelled out in detail.
∂04-May-89 1251 CL-Cleanup-mailer Issue: SETF-MULTIPLE-STORE-VARIABLE
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 4 May 89 12:51:39 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 589900; 4 May 89 15:52:19 EDT
Date: Thu, 4 May 89 15:52 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: SETF-MULTIPLE-STORE-VARIABLE
To: rao@arisia.Xerox.COM
cc: cl-cleanup@sail.stanford.edu, pavel.pa@Xerox.COM, gregor@arisia.Xerox.COM,
masinter.pa@arisia.Xerox.COM
In-Reply-To: <8905041621.AA05410@layla.>
Message-ID: <19890504195216.1.MOON@EUPHRATES.SCRC.Symbolics.COM>
Line-fold: No
Date: Thu, 4 May 89 09:21:58 PDT
From: Ramana Rao <rao@arisia.Xerox.COM>
This message is to encourage the cleanup committee to get to and accept this
proposal
We'd better! June?
and to bring up a related issue having to do with setf generic functions in CLOS.
setf generic functions, like the short form of defsetf, only work for storing single
values. To store multiple values you need to use the long form of defsetf or
define-setf-method. I don't think it's at all hard to make a macro that expands
into a defmethod and a defsetf. It's probably not worth trying to change the
syntax of defmethod to be that macro (I think we already considered that a couple
years ago and uncovered some problems).